Skip to content

Conversation

@GrayJack
Copy link
Contributor

@GrayJack GrayJack commented Jan 3, 2026

Name updates based on PSPlibdoc

The type SceBootCallback will be used on more modules (according to uofw), that is why I added to pspkerneltypes.h

#endif
#ifdef F_InitForKernel_0001
IMPORT_FUNC "InitForKernel",0x1D3256BA,sceKernelRegisterChunk
IMPORT_FUNC "InitForKernel",0x1D3256BA,sceKernelRegisterChunk
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'm staring at this and other similar hunks and fail to see any change - probably replaced a tab with a space or vice versa ?

Copy link
Contributor Author

@GrayJack GrayJack Jan 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is weird, this was not in the git diff and I did not change a single thing on this besides the function name changes. Maybe GitHub is using a different diff algo?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This same thing hapenned on line 37 on Makefile.am

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe GitHub is using a different diff algo?

unlikely. could it be that you use a mac or windows pc and newlines \n were replaced with \r or \r\n, only on lines you touched ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I am on macOS, but my editor for sure in configured with LF line ending

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's the other way round - your editor replaced existing CRLF with LF. to find out
i condensed your commits into a single one (git rebase -i) and made a format-patch, which i then opened with hexedit.

000002E0   30 30 30 31  0A 2D 09 49  4D 50 4F 52  54 5F 46 55  0001.-.IMPORT_FU
000002F0   4E 43 09 22  49 6E 69 74  46 6F 72 4B  65 72 6E 65  NC."InitForKerne
00000300   6C 22 2C 30  78 31 44 33  32 35 36 42  41 2C 73 63  l",0x1D3256BA,sc
00000310   65 4B 65 72  6E 65 6C 52  65 67 69 73  74 65 72 43  eKernelRegisterC
00000320   68 75 6E 6B  **0D 0A** 2B 09  49 4D 50 4F  52 54 5F 46  hunk..+.IMPORT_F
00000330   55 4E 43 09  22 49 6E 69  74 46 6F 72  4B 65 72 6E  UNC."InitForKern
00000340   65 6C 22 2C  30 78 31 44  33 32 35 36  42 41 2C 73  el",0x1D3256BA,s
00000350   63 65 4B 65  72 6E 65 6C  52 65 67 69  73 74 65 72  ceKernelRegister
00000360   43 68 75 6E  6B **0A** 20 23  65 6E 64 69  66 0A 20 23  Chunk. #endif. #

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then it makes sense this diff, although it sure is not showing in the diff localy. Btw, it doesn't make sense, so far all files I tweaked (not only the ones I made PR), all of them are LF, why a random file is CRLF?

I'll "fix" this tomorrow. Thanks for finding this issue

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

although it sure is not showing in the diff localy.

that's likely because this PR consists of like 5 separate commits, i didnt see it either before i squashed them all together.

all files I tweaked (not only the ones I made PR), all of them are LF, why a random file is CRLF?

i think the file is a mix of CRLF and LF, most editors and tools don't care about it so it flies below the radar, but when a line is touched or added that line is changed to the editor's default. fixing it (to keep diffs minimal) either requires using a hexeditor that can insert new bytes at arbitrary positions such as hexedit, or squashing the commits into one like i did, and either 1) creating a format-patch, and removing the hunks with the line-end changes with an editor, then deleting the old commits and applying the patch, or 2) unstage the changes, and selectively re-adding hunks with git add --patch, which is likely more practical since the text gui allows to shrink hunks that span over multiple blocks with s.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants