Files

226 lines
4.7 KiB
C
Raw Permalink Normal View History

Use LF line endings in the repository Convert the line endings stored for all text files in the repository to LF. The majority previously used DOS-style CRLF line endings. Add a .gitattributes file to enforce this and treat certain extensions as never being text files. Update PatchCheck.py to insist on LF line endings rather than CRLF. However, its other checks fail on this commit due to lots of pre-existing complaints that it only notices because the line endings have changed. Silicon/QemuSocPkg/FspBin/Patches/0001-Build-QEMU-FSP-2.0-binaries.patch needs to be treated as binary since it contains a mixture of line endings. This change has implications depending on the client platform you are using the repository from: * Windows The usual configuration for Git on Windows means that text files will be checked out to the work tree with DOS-style CRLF line endings. If that's not the case then you can configure Git to do so for the entire machine with: git config --global core.autocrlf true or for just the repository with: git config core.autocrlf true Line endings will be normalised to LF when they are committed to the repository. If you commit a text file with only LF line endings then it will be converted to CRLF line endings in your work tree. * Linux, MacOS and other Unices The usual configuration for Git on such platforms is to check files out of the repository with LF line endings. This is probably the right thing for you. In the unlikely even that you are using Git on Unix but editing or compiling on Windows for some reason then you may need to tweak your configuration to force the use of CRLF line endings as described above. * General For more information see https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings . Fixes: https://github.com/slimbootloader/slimbootloader/issues/1400 Signed-off-by: Mike Crowe <mac@mcrowe.com>
2021-11-10 11:36:23 +00:00
/** @file
This contains some useful functions for accessing files.
Copyright (c) 2004 - 2018, Intel Corporation. All rights reserved.<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent
**/
#include <assert.h>
#include <string.h>
#include <ctype.h>
#include <stdlib.h>
#include "CommonLib.h"
#include "MemoryFile.h"
//
// Local (static) function prototypes
//
STATIC
VOID
CheckMemoryFileState (
IN EFI_HANDLE InputMemoryFile
);
//
// Function implementations
//
/**
This opens a file, reads it into memory and returns a memory file
object.
@param InputFile Memory file image.
@param OutputMemoryFile Handle to memory file
@return EFI_STATUS
OutputMemoryFile is valid if !EFI_ERROR
**/
Use LF line endings in the repository Convert the line endings stored for all text files in the repository to LF. The majority previously used DOS-style CRLF line endings. Add a .gitattributes file to enforce this and treat certain extensions as never being text files. Update PatchCheck.py to insist on LF line endings rather than CRLF. However, its other checks fail on this commit due to lots of pre-existing complaints that it only notices because the line endings have changed. Silicon/QemuSocPkg/FspBin/Patches/0001-Build-QEMU-FSP-2.0-binaries.patch needs to be treated as binary since it contains a mixture of line endings. This change has implications depending on the client platform you are using the repository from: * Windows The usual configuration for Git on Windows means that text files will be checked out to the work tree with DOS-style CRLF line endings. If that's not the case then you can configure Git to do so for the entire machine with: git config --global core.autocrlf true or for just the repository with: git config core.autocrlf true Line endings will be normalised to LF when they are committed to the repository. If you commit a text file with only LF line endings then it will be converted to CRLF line endings in your work tree. * Linux, MacOS and other Unices The usual configuration for Git on such platforms is to check files out of the repository with LF line endings. This is probably the right thing for you. In the unlikely even that you are using Git on Unix but editing or compiling on Windows for some reason then you may need to tweak your configuration to force the use of CRLF line endings as described above. * General For more information see https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings . Fixes: https://github.com/slimbootloader/slimbootloader/issues/1400 Signed-off-by: Mike Crowe <mac@mcrowe.com>
2021-11-10 11:36:23 +00:00
EFI_STATUS
GetMemoryFile (
IN CHAR8 *InputFileName,
OUT EFI_HANDLE *OutputMemoryFile
)
{
EFI_STATUS Status;
CHAR8 *InputFileImage;
UINT32 BytesRead;
MEMORY_FILE *NewMemoryFile;
Status = GetFileImage (InputFileName, &InputFileImage, &BytesRead);
if (EFI_ERROR (Status)) {
return Status;
}
NewMemoryFile = malloc (sizeof (*NewMemoryFile));
if (NewMemoryFile == NULL) {
free (InputFileImage);
return EFI_OUT_OF_RESOURCES;
}
NewMemoryFile->FileImage = InputFileImage;
NewMemoryFile->CurrentFilePointer = InputFileImage;
NewMemoryFile->Eof = InputFileImage + BytesRead;
*OutputMemoryFile = (EFI_HANDLE)NewMemoryFile;
CheckMemoryFileState (*OutputMemoryFile);
return EFI_SUCCESS;
}
/**
Frees all memory associated with the input memory file.
Use LF line endings in the repository Convert the line endings stored for all text files in the repository to LF. The majority previously used DOS-style CRLF line endings. Add a .gitattributes file to enforce this and treat certain extensions as never being text files. Update PatchCheck.py to insist on LF line endings rather than CRLF. However, its other checks fail on this commit due to lots of pre-existing complaints that it only notices because the line endings have changed. Silicon/QemuSocPkg/FspBin/Patches/0001-Build-QEMU-FSP-2.0-binaries.patch needs to be treated as binary since it contains a mixture of line endings. This change has implications depending on the client platform you are using the repository from: * Windows The usual configuration for Git on Windows means that text files will be checked out to the work tree with DOS-style CRLF line endings. If that's not the case then you can configure Git to do so for the entire machine with: git config --global core.autocrlf true or for just the repository with: git config core.autocrlf true Line endings will be normalised to LF when they are committed to the repository. If you commit a text file with only LF line endings then it will be converted to CRLF line endings in your work tree. * Linux, MacOS and other Unices The usual configuration for Git on such platforms is to check files out of the repository with LF line endings. This is probably the right thing for you. In the unlikely even that you are using Git on Unix but editing or compiling on Windows for some reason then you may need to tweak your configuration to force the use of CRLF line endings as described above. * General For more information see https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings . Fixes: https://github.com/slimbootloader/slimbootloader/issues/1400 Signed-off-by: Mike Crowe <mac@mcrowe.com>
2021-11-10 11:36:23 +00:00
@param InputMemoryFile Handle to memory file
@return EFI_STATUS
**/
Use LF line endings in the repository Convert the line endings stored for all text files in the repository to LF. The majority previously used DOS-style CRLF line endings. Add a .gitattributes file to enforce this and treat certain extensions as never being text files. Update PatchCheck.py to insist on LF line endings rather than CRLF. However, its other checks fail on this commit due to lots of pre-existing complaints that it only notices because the line endings have changed. Silicon/QemuSocPkg/FspBin/Patches/0001-Build-QEMU-FSP-2.0-binaries.patch needs to be treated as binary since it contains a mixture of line endings. This change has implications depending on the client platform you are using the repository from: * Windows The usual configuration for Git on Windows means that text files will be checked out to the work tree with DOS-style CRLF line endings. If that's not the case then you can configure Git to do so for the entire machine with: git config --global core.autocrlf true or for just the repository with: git config core.autocrlf true Line endings will be normalised to LF when they are committed to the repository. If you commit a text file with only LF line endings then it will be converted to CRLF line endings in your work tree. * Linux, MacOS and other Unices The usual configuration for Git on such platforms is to check files out of the repository with LF line endings. This is probably the right thing for you. In the unlikely even that you are using Git on Unix but editing or compiling on Windows for some reason then you may need to tweak your configuration to force the use of CRLF line endings as described above. * General For more information see https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings . Fixes: https://github.com/slimbootloader/slimbootloader/issues/1400 Signed-off-by: Mike Crowe <mac@mcrowe.com>
2021-11-10 11:36:23 +00:00
EFI_STATUS
FreeMemoryFile (
IN EFI_HANDLE InputMemoryFile
)
{
MEMORY_FILE *MemoryFile;
CheckMemoryFileState (InputMemoryFile);
MemoryFile = (MEMORY_FILE*)InputMemoryFile;
free (MemoryFile->FileImage);
//
// Invalidate state of MEMORY_FILE structure to catch invalid usage.
//
memset (MemoryFile, 0xcc, sizeof (*MemoryFile));
MemoryFile->Eof -= 1;
free (MemoryFile);
return EFI_SUCCESS;
}
/**
Use LF line endings in the repository Convert the line endings stored for all text files in the repository to LF. The majority previously used DOS-style CRLF line endings. Add a .gitattributes file to enforce this and treat certain extensions as never being text files. Update PatchCheck.py to insist on LF line endings rather than CRLF. However, its other checks fail on this commit due to lots of pre-existing complaints that it only notices because the line endings have changed. Silicon/QemuSocPkg/FspBin/Patches/0001-Build-QEMU-FSP-2.0-binaries.patch needs to be treated as binary since it contains a mixture of line endings. This change has implications depending on the client platform you are using the repository from: * Windows The usual configuration for Git on Windows means that text files will be checked out to the work tree with DOS-style CRLF line endings. If that's not the case then you can configure Git to do so for the entire machine with: git config --global core.autocrlf true or for just the repository with: git config core.autocrlf true Line endings will be normalised to LF when they are committed to the repository. If you commit a text file with only LF line endings then it will be converted to CRLF line endings in your work tree. * Linux, MacOS and other Unices The usual configuration for Git on such platforms is to check files out of the repository with LF line endings. This is probably the right thing for you. In the unlikely even that you are using Git on Unix but editing or compiling on Windows for some reason then you may need to tweak your configuration to force the use of CRLF line endings as described above. * General For more information see https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings . Fixes: https://github.com/slimbootloader/slimbootloader/issues/1400 Signed-off-by: Mike Crowe <mac@mcrowe.com>
2021-11-10 11:36:23 +00:00
This function reads a line from the memory file. The newline characters
are stripped and a null terminated string is returned.
If the string pointer returned is non-NULL, then the caller must free the
memory associated with this string.
@param InputMemoryFile Handle to memory file
Use LF line endings in the repository Convert the line endings stored for all text files in the repository to LF. The majority previously used DOS-style CRLF line endings. Add a .gitattributes file to enforce this and treat certain extensions as never being text files. Update PatchCheck.py to insist on LF line endings rather than CRLF. However, its other checks fail on this commit due to lots of pre-existing complaints that it only notices because the line endings have changed. Silicon/QemuSocPkg/FspBin/Patches/0001-Build-QEMU-FSP-2.0-binaries.patch needs to be treated as binary since it contains a mixture of line endings. This change has implications depending on the client platform you are using the repository from: * Windows The usual configuration for Git on Windows means that text files will be checked out to the work tree with DOS-style CRLF line endings. If that's not the case then you can configure Git to do so for the entire machine with: git config --global core.autocrlf true or for just the repository with: git config core.autocrlf true Line endings will be normalised to LF when they are committed to the repository. If you commit a text file with only LF line endings then it will be converted to CRLF line endings in your work tree. * Linux, MacOS and other Unices The usual configuration for Git on such platforms is to check files out of the repository with LF line endings. This is probably the right thing for you. In the unlikely even that you are using Git on Unix but editing or compiling on Windows for some reason then you may need to tweak your configuration to force the use of CRLF line endings as described above. * General For more information see https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings . Fixes: https://github.com/slimbootloader/slimbootloader/issues/1400 Signed-off-by: Mike Crowe <mac@mcrowe.com>
2021-11-10 11:36:23 +00:00
@retval NULL if error or EOF
@retval NULL character termincated string otherwise (MUST BE FREED BY CALLER)
**/
CHAR8 *
ReadMemoryFileLine (
IN EFI_HANDLE InputMemoryFile
)
Use LF line endings in the repository Convert the line endings stored for all text files in the repository to LF. The majority previously used DOS-style CRLF line endings. Add a .gitattributes file to enforce this and treat certain extensions as never being text files. Update PatchCheck.py to insist on LF line endings rather than CRLF. However, its other checks fail on this commit due to lots of pre-existing complaints that it only notices because the line endings have changed. Silicon/QemuSocPkg/FspBin/Patches/0001-Build-QEMU-FSP-2.0-binaries.patch needs to be treated as binary since it contains a mixture of line endings. This change has implications depending on the client platform you are using the repository from: * Windows The usual configuration for Git on Windows means that text files will be checked out to the work tree with DOS-style CRLF line endings. If that's not the case then you can configure Git to do so for the entire machine with: git config --global core.autocrlf true or for just the repository with: git config core.autocrlf true Line endings will be normalised to LF when they are committed to the repository. If you commit a text file with only LF line endings then it will be converted to CRLF line endings in your work tree. * Linux, MacOS and other Unices The usual configuration for Git on such platforms is to check files out of the repository with LF line endings. This is probably the right thing for you. In the unlikely even that you are using Git on Unix but editing or compiling on Windows for some reason then you may need to tweak your configuration to force the use of CRLF line endings as described above. * General For more information see https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings . Fixes: https://github.com/slimbootloader/slimbootloader/issues/1400 Signed-off-by: Mike Crowe <mac@mcrowe.com>
2021-11-10 11:36:23 +00:00
{
CHAR8 *EndOfLine;
UINTN CharsToCopy;
MEMORY_FILE *InputFile;
UINTN BytesToEof;
CHAR8 *OutputString;
//
// Verify input parameters are not null
//
CheckMemoryFileState (InputMemoryFile);
InputFile = (MEMORY_FILE*)InputMemoryFile;
//
// Check for end of file condition
//
if (InputFile->CurrentFilePointer >= InputFile->Eof) {
return NULL;
}
//
// Determine the number of bytes remaining until the EOF
//
BytesToEof = InputFile->Eof - InputFile->CurrentFilePointer;
//
// Find the next newline char
//
EndOfLine = memchr (InputFile->CurrentFilePointer, '\n', BytesToEof);
//
// Determine the number of characters to copy.
//
if (EndOfLine == 0) {
//
// If no newline found, copy to the end of the file.
//
CharsToCopy = InputFile->Eof - InputFile->CurrentFilePointer;
} else {
//
// Newline found in the file.
//
CharsToCopy = EndOfLine - InputFile->CurrentFilePointer;
}
OutputString = malloc (CharsToCopy + 1);
if (OutputString == NULL) {
return NULL;
}
//
// Copy the line.
//
memcpy (OutputString, InputFile->CurrentFilePointer, CharsToCopy);
//
// Add the null termination over the 0x0D
//
if (OutputString[CharsToCopy - 1] == '\r') {
OutputString[CharsToCopy - 1] = '\0';
} else {
OutputString[CharsToCopy] = '\0';
}
//
// Increment the current file pointer (include the 0x0A)
//
InputFile->CurrentFilePointer += CharsToCopy + 1;
if (InputFile->CurrentFilePointer > InputFile->Eof) {
InputFile->CurrentFilePointer = InputFile->Eof;
}
CheckMemoryFileState (InputMemoryFile);
//
// Return the string
//
return OutputString;
}
STATIC
VOID
CheckMemoryFileState (
IN EFI_HANDLE InputMemoryFile
)
{
MEMORY_FILE *MemoryFile;
assert (InputMemoryFile != NULL);
MemoryFile = (MEMORY_FILE*)InputMemoryFile;
assert (MemoryFile->FileImage != NULL);
assert (MemoryFile->CurrentFilePointer != NULL);
assert (MemoryFile->Eof != NULL);
assert (MemoryFile->Eof >= MemoryFile->FileImage);
assert (MemoryFile->CurrentFilePointer >= MemoryFile->FileImage);
assert (MemoryFile->CurrentFilePointer <= MemoryFile->Eof);
}