Searched hist:4 (Results 101 - 125 of 3871) sorted by relevance
/haiku/3rdparty/korli/ | ||
H A D | haiku-current.list | 4a55cc23 Mon Oct 24 12:12:59 MDT 2022 Jérôme Duval <jerome.duval@gmail.com> script to parse supported ids for network drivers format similar to lkddb Change-Id: Ie46becca48d4d8b7b37106f28c68dd6f60fa3322 Reviewed-on: https://review.haiku-os.org/c/haiku/+/5761 Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org> Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk> |
/haiku/src/preferences/keymap/ | ||
H A D | StatusMenuField.cpp | 4fc18643 Mon Dec 04 18:55:54 MST 2023 John Scipione <jscipione@gmail.com> Keymap: Put status icons inside menu fields Draw warning and stop icons on top of the menu fields instead. Remove conflict views, create a new file to hold StatusMenuField and StatusMenuItem. Set the icon with them instead. Change-Id: If6c00199f24ac4f4fc789f12cc6cdcd7a912418f Reviewed-on: https://review.haiku-os.org/c/haiku/+/7209 Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk> Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org> |
H A D | StatusMenuField.h | 4fc18643 Mon Dec 04 18:55:54 MST 2023 John Scipione <jscipione@gmail.com> Keymap: Put status icons inside menu fields Draw warning and stop icons on top of the menu fields instead. Remove conflict views, create a new file to hold StatusMenuField and StatusMenuItem. Set the icon with them instead. Change-Id: If6c00199f24ac4f4fc789f12cc6cdcd7a912418f Reviewed-on: https://review.haiku-os.org/c/haiku/+/7209 Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk> Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org> |
/haiku/src/bin/network/ping/ | ||
H A D | ping.h | 3bf4cdb7 Sat Feb 24 08:51:04 MST 2024 Jérôme Duval <jerome.duval@gmail.com> network/ping: update to freebsd-current * our ip modules don't support connect()/send(). Just use sendto(). * ping6 disappears, ping supports -4 or -6 to force IPv4 or IPv6 Change-Id: I1e982e354cc75d3a314c5bbbfffa0373e8f4d9af Reviewed-on: https://review.haiku-os.org/c/haiku/+/7427 Reviewed-by: waddlesplash <waddlesplash@gmail.com> |
H A D | ping6.h | 3bf4cdb7 Sat Feb 24 08:51:04 MST 2024 Jérôme Duval <jerome.duval@gmail.com> network/ping: update to freebsd-current * our ip modules don't support connect()/send(). Just use sendto(). * ping6 disappears, ping supports -4 or -6 to force IPv4 or IPv6 Change-Id: I1e982e354cc75d3a314c5bbbfffa0373e8f4d9af Reviewed-on: https://review.haiku-os.org/c/haiku/+/7427 Reviewed-by: waddlesplash <waddlesplash@gmail.com> |
H A D | utils.c | 3bf4cdb7 Sat Feb 24 08:51:04 MST 2024 Jérôme Duval <jerome.duval@gmail.com> network/ping: update to freebsd-current * our ip modules don't support connect()/send(). Just use sendto(). * ping6 disappears, ping supports -4 or -6 to force IPv4 or IPv6 Change-Id: I1e982e354cc75d3a314c5bbbfffa0373e8f4d9af Reviewed-on: https://review.haiku-os.org/c/haiku/+/7427 Reviewed-by: waddlesplash <waddlesplash@gmail.com> |
H A D | utils.h | 3bf4cdb7 Sat Feb 24 08:51:04 MST 2024 Jérôme Duval <jerome.duval@gmail.com> network/ping: update to freebsd-current * our ip modules don't support connect()/send(). Just use sendto(). * ping6 disappears, ping supports -4 or -6 to force IPv4 or IPv6 Change-Id: I1e982e354cc75d3a314c5bbbfffa0373e8f4d9af Reviewed-on: https://review.haiku-os.org/c/haiku/+/7427 Reviewed-by: waddlesplash <waddlesplash@gmail.com> |
H A D | main.h | 3bf4cdb7 Sat Feb 24 08:51:04 MST 2024 Jérôme Duval <jerome.duval@gmail.com> network/ping: update to freebsd-current * our ip modules don't support connect()/send(). Just use sendto(). * ping6 disappears, ping supports -4 or -6 to force IPv4 or IPv6 Change-Id: I1e982e354cc75d3a314c5bbbfffa0373e8f4d9af Reviewed-on: https://review.haiku-os.org/c/haiku/+/7427 Reviewed-by: waddlesplash <waddlesplash@gmail.com> |
/haiku/data/catalogs/preferences/sounds/ | ||
H A D | tr.catkeys | diff 4a7de3f1 Sat Mar 30 02:17:22 MDT 2024 Autocomitter <noreply@haiku-os.org> Update translations from Pootle |
/haiku/src/add-ons/accelerants/radeon/ | ||
H A D | theatre_out.c | diff 758b1d0e Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e05fe1042cce6e00d194a147802d4f9be Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e05fe1042cce6e00d194a147802d4f9be Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e05fe1042cce6e00d194a147802d4f9be Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
/haiku/src/add-ons/kernel/file_systems/exfat/ | ||
H A D | DirectoryIterator.h | diff ebd3bcdb Wed Feb 12 18:15:18 MST 2014 John Scipione <jscipione@gmail.com> exfat: handle 4-byte UTF-16 surrogate pairs ... in filenames. Replace the existing Unicode conversion functions with UTF conversion functions from js that he relicensed MIT for us. Put the UTF conversion functions in a private but shared code location so that they can be accessed throughout the kernel. Right now we only provide functions to convert between UTF-8 and UTF-16. At some point we should also add functions to convert between UTF-8 and UTF-32 and UTF-16 and UTF-32 but these aren't needed by exfat. Remove the old Unicode conversion functions from exfat as they assumed UCS-2 characters and don't work with UTF-16 used by exfat. Rename most variables with the term length with code unit where code units are intended. The term length, when used, means length in bytes while code units represent either a full 2-byte UTF-16 character or half a 4-byte surrogate pair. diff ebd3bcdb Wed Feb 12 18:15:18 MST 2014 John Scipione <jscipione@gmail.com> exfat: handle 4-byte UTF-16 surrogate pairs ... in filenames. Replace the existing Unicode conversion functions with UTF conversion functions from js that he relicensed MIT for us. Put the UTF conversion functions in a private but shared code location so that they can be accessed throughout the kernel. Right now we only provide functions to convert between UTF-8 and UTF-16. At some point we should also add functions to convert between UTF-8 and UTF-32 and UTF-16 and UTF-32 but these aren't needed by exfat. Remove the old Unicode conversion functions from exfat as they assumed UCS-2 characters and don't work with UTF-16 used by exfat. Rename most variables with the term length with code unit where code units are intended. The term length, when used, means length in bytes while code units represent either a full 2-byte UTF-16 character or half a 4-byte surrogate pair. diff e74e90ae Wed Feb 09 13:08:48 MST 2011 Jérôme Duval <korli@users.berlios.de> * Implemented a read-only exFAT file system, tested with a 4GB image. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40409 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff ebd3bcdb9be2d6a57fc5b3270dcb49a9e1894d11 Wed Feb 12 18:15:18 MST 2014 John Scipione <jscipione@gmail.com> exfat: handle 4-byte UTF-16 surrogate pairs ... in filenames. Replace the existing Unicode conversion functions with UTF conversion functions from js that he relicensed MIT for us. Put the UTF conversion functions in a private but shared code location so that they can be accessed throughout the kernel. Right now we only provide functions to convert between UTF-8 and UTF-16. At some point we should also add functions to convert between UTF-8 and UTF-32 and UTF-16 and UTF-32 but these aren't needed by exfat. Remove the old Unicode conversion functions from exfat as they assumed UCS-2 characters and don't work with UTF-16 used by exfat. Rename most variables with the term length with code unit where code units are intended. The term length, when used, means length in bytes while code units represent either a full 2-byte UTF-16 character or half a 4-byte surrogate pair. diff ebd3bcdb9be2d6a57fc5b3270dcb49a9e1894d11 Wed Feb 12 18:15:18 MST 2014 John Scipione <jscipione@gmail.com> exfat: handle 4-byte UTF-16 surrogate pairs ... in filenames. Replace the existing Unicode conversion functions with UTF conversion functions from js that he relicensed MIT for us. Put the UTF conversion functions in a private but shared code location so that they can be accessed throughout the kernel. Right now we only provide functions to convert between UTF-8 and UTF-16. At some point we should also add functions to convert between UTF-8 and UTF-32 and UTF-16 and UTF-32 but these aren't needed by exfat. Remove the old Unicode conversion functions from exfat as they assumed UCS-2 characters and don't work with UTF-16 used by exfat. Rename most variables with the term length with code unit where code units are intended. The term length, when used, means length in bytes while code units represent either a full 2-byte UTF-16 character or half a 4-byte surrogate pair. e74e90aef91f844d4d3654504cd0776c26a454e5 Wed Feb 09 13:08:48 MST 2011 Jérôme Duval <korli@users.berlios.de> * Implemented a read-only exFAT file system, tested with a 4GB image. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40409 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
H A D | exfat.h | diff ebd3bcdb Wed Feb 12 18:15:18 MST 2014 John Scipione <jscipione@gmail.com> exfat: handle 4-byte UTF-16 surrogate pairs ... in filenames. Replace the existing Unicode conversion functions with UTF conversion functions from js that he relicensed MIT for us. Put the UTF conversion functions in a private but shared code location so that they can be accessed throughout the kernel. Right now we only provide functions to convert between UTF-8 and UTF-16. At some point we should also add functions to convert between UTF-8 and UTF-32 and UTF-16 and UTF-32 but these aren't needed by exfat. Remove the old Unicode conversion functions from exfat as they assumed UCS-2 characters and don't work with UTF-16 used by exfat. Rename most variables with the term length with code unit where code units are intended. The term length, when used, means length in bytes while code units represent either a full 2-byte UTF-16 character or half a 4-byte surrogate pair. diff ebd3bcdb Wed Feb 12 18:15:18 MST 2014 John Scipione <jscipione@gmail.com> exfat: handle 4-byte UTF-16 surrogate pairs ... in filenames. Replace the existing Unicode conversion functions with UTF conversion functions from js that he relicensed MIT for us. Put the UTF conversion functions in a private but shared code location so that they can be accessed throughout the kernel. Right now we only provide functions to convert between UTF-8 and UTF-16. At some point we should also add functions to convert between UTF-8 and UTF-32 and UTF-16 and UTF-32 but these aren't needed by exfat. Remove the old Unicode conversion functions from exfat as they assumed UCS-2 characters and don't work with UTF-16 used by exfat. Rename most variables with the term length with code unit where code units are intended. The term length, when used, means length in bytes while code units represent either a full 2-byte UTF-16 character or half a 4-byte surrogate pair. diff 5b10d763 Tue Feb 11 11:13:53 MST 2014 John Scipione <jscipione@gmail.com> exfat: use diff structs 4 vol labels and filenames ... and rename the structs to reflect this. * Volume labels contain up to 11 uint16s (11 2-byte UTF-16 characters). * Filenames are packed into 1 to 17 structs of 15 uint16s each (for a total of 255 2-byte UTF-16 characters). * Use 2 different packed structs in the exfat_entry union (same bytes, accessed with different structs) to access these 2 things. * Remove a check that assumed the length returned the number of 2-byte UTF-16 characters, i.e. the number of uint16s the string uses. It doesn't, it returns the number of characters contained in the string which might be 2 or 4-bytes wide. We're doing the conversion wrong for 4-byte UTF-16 characters anyway, more on that later. diff 5b10d763 Tue Feb 11 11:13:53 MST 2014 John Scipione <jscipione@gmail.com> exfat: use diff structs 4 vol labels and filenames ... and rename the structs to reflect this. * Volume labels contain up to 11 uint16s (11 2-byte UTF-16 characters). * Filenames are packed into 1 to 17 structs of 15 uint16s each (for a total of 255 2-byte UTF-16 characters). * Use 2 different packed structs in the exfat_entry union (same bytes, accessed with different structs) to access these 2 things. * Remove a check that assumed the length returned the number of 2-byte UTF-16 characters, i.e. the number of uint16s the string uses. It doesn't, it returns the number of characters contained in the string which might be 2 or 4-bytes wide. We're doing the conversion wrong for 4-byte UTF-16 characters anyway, more on that later. diff 5b10d763 Tue Feb 11 11:13:53 MST 2014 John Scipione <jscipione@gmail.com> exfat: use diff structs 4 vol labels and filenames ... and rename the structs to reflect this. * Volume labels contain up to 11 uint16s (11 2-byte UTF-16 characters). * Filenames are packed into 1 to 17 structs of 15 uint16s each (for a total of 255 2-byte UTF-16 characters). * Use 2 different packed structs in the exfat_entry union (same bytes, accessed with different structs) to access these 2 things. * Remove a check that assumed the length returned the number of 2-byte UTF-16 characters, i.e. the number of uint16s the string uses. It doesn't, it returns the number of characters contained in the string which might be 2 or 4-bytes wide. We're doing the conversion wrong for 4-byte UTF-16 characters anyway, more on that later. diff e74e90ae Wed Feb 09 13:08:48 MST 2011 Jérôme Duval <korli@users.berlios.de> * Implemented a read-only exFAT file system, tested with a 4GB image. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40409 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff ebd3bcdb9be2d6a57fc5b3270dcb49a9e1894d11 Wed Feb 12 18:15:18 MST 2014 John Scipione <jscipione@gmail.com> exfat: handle 4-byte UTF-16 surrogate pairs ... in filenames. Replace the existing Unicode conversion functions with UTF conversion functions from js that he relicensed MIT for us. Put the UTF conversion functions in a private but shared code location so that they can be accessed throughout the kernel. Right now we only provide functions to convert between UTF-8 and UTF-16. At some point we should also add functions to convert between UTF-8 and UTF-32 and UTF-16 and UTF-32 but these aren't needed by exfat. Remove the old Unicode conversion functions from exfat as they assumed UCS-2 characters and don't work with UTF-16 used by exfat. Rename most variables with the term length with code unit where code units are intended. The term length, when used, means length in bytes while code units represent either a full 2-byte UTF-16 character or half a 4-byte surrogate pair. diff ebd3bcdb9be2d6a57fc5b3270dcb49a9e1894d11 Wed Feb 12 18:15:18 MST 2014 John Scipione <jscipione@gmail.com> exfat: handle 4-byte UTF-16 surrogate pairs ... in filenames. Replace the existing Unicode conversion functions with UTF conversion functions from js that he relicensed MIT for us. Put the UTF conversion functions in a private but shared code location so that they can be accessed throughout the kernel. Right now we only provide functions to convert between UTF-8 and UTF-16. At some point we should also add functions to convert between UTF-8 and UTF-32 and UTF-16 and UTF-32 but these aren't needed by exfat. Remove the old Unicode conversion functions from exfat as they assumed UCS-2 characters and don't work with UTF-16 used by exfat. Rename most variables with the term length with code unit where code units are intended. The term length, when used, means length in bytes while code units represent either a full 2-byte UTF-16 character or half a 4-byte surrogate pair. diff 5b10d763d0da84a6f0cb07c610eb25df776273b2 Tue Feb 11 11:13:53 MST 2014 John Scipione <jscipione@gmail.com> exfat: use diff structs 4 vol labels and filenames ... and rename the structs to reflect this. * Volume labels contain up to 11 uint16s (11 2-byte UTF-16 characters). * Filenames are packed into 1 to 17 structs of 15 uint16s each (for a total of 255 2-byte UTF-16 characters). * Use 2 different packed structs in the exfat_entry union (same bytes, accessed with different structs) to access these 2 things. * Remove a check that assumed the length returned the number of 2-byte UTF-16 characters, i.e. the number of uint16s the string uses. It doesn't, it returns the number of characters contained in the string which might be 2 or 4-bytes wide. We're doing the conversion wrong for 4-byte UTF-16 characters anyway, more on that later. diff 5b10d763d0da84a6f0cb07c610eb25df776273b2 Tue Feb 11 11:13:53 MST 2014 John Scipione <jscipione@gmail.com> exfat: use diff structs 4 vol labels and filenames ... and rename the structs to reflect this. * Volume labels contain up to 11 uint16s (11 2-byte UTF-16 characters). * Filenames are packed into 1 to 17 structs of 15 uint16s each (for a total of 255 2-byte UTF-16 characters). * Use 2 different packed structs in the exfat_entry union (same bytes, accessed with different structs) to access these 2 things. * Remove a check that assumed the length returned the number of 2-byte UTF-16 characters, i.e. the number of uint16s the string uses. It doesn't, it returns the number of characters contained in the string which might be 2 or 4-bytes wide. We're doing the conversion wrong for 4-byte UTF-16 characters anyway, more on that later. diff 5b10d763d0da84a6f0cb07c610eb25df776273b2 Tue Feb 11 11:13:53 MST 2014 John Scipione <jscipione@gmail.com> exfat: use diff structs 4 vol labels and filenames ... and rename the structs to reflect this. * Volume labels contain up to 11 uint16s (11 2-byte UTF-16 characters). * Filenames are packed into 1 to 17 structs of 15 uint16s each (for a total of 255 2-byte UTF-16 characters). * Use 2 different packed structs in the exfat_entry union (same bytes, accessed with different structs) to access these 2 things. * Remove a check that assumed the length returned the number of 2-byte UTF-16 characters, i.e. the number of uint16s the string uses. It doesn't, it returns the number of characters contained in the string which might be 2 or 4-bytes wide. We're doing the conversion wrong for 4-byte UTF-16 characters anyway, more on that later. |
H A D | Jamfile | diff ebd3bcdb Wed Feb 12 18:15:18 MST 2014 John Scipione <jscipione@gmail.com> exfat: handle 4-byte UTF-16 surrogate pairs ... in filenames. Replace the existing Unicode conversion functions with UTF conversion functions from js that he relicensed MIT for us. Put the UTF conversion functions in a private but shared code location so that they can be accessed throughout the kernel. Right now we only provide functions to convert between UTF-8 and UTF-16. At some point we should also add functions to convert between UTF-8 and UTF-32 and UTF-16 and UTF-32 but these aren't needed by exfat. Remove the old Unicode conversion functions from exfat as they assumed UCS-2 characters and don't work with UTF-16 used by exfat. Rename most variables with the term length with code unit where code units are intended. The term length, when used, means length in bytes while code units represent either a full 2-byte UTF-16 character or half a 4-byte surrogate pair. diff ebd3bcdb Wed Feb 12 18:15:18 MST 2014 John Scipione <jscipione@gmail.com> exfat: handle 4-byte UTF-16 surrogate pairs ... in filenames. Replace the existing Unicode conversion functions with UTF conversion functions from js that he relicensed MIT for us. Put the UTF conversion functions in a private but shared code location so that they can be accessed throughout the kernel. Right now we only provide functions to convert between UTF-8 and UTF-16. At some point we should also add functions to convert between UTF-8 and UTF-32 and UTF-16 and UTF-32 but these aren't needed by exfat. Remove the old Unicode conversion functions from exfat as they assumed UCS-2 characters and don't work with UTF-16 used by exfat. Rename most variables with the term length with code unit where code units are intended. The term length, when used, means length in bytes while code units represent either a full 2-byte UTF-16 character or half a 4-byte surrogate pair. diff e74e90ae Wed Feb 09 13:08:48 MST 2011 Jérôme Duval <korli@users.berlios.de> * Implemented a read-only exFAT file system, tested with a 4GB image. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40409 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff ebd3bcdb9be2d6a57fc5b3270dcb49a9e1894d11 Wed Feb 12 18:15:18 MST 2014 John Scipione <jscipione@gmail.com> exfat: handle 4-byte UTF-16 surrogate pairs ... in filenames. Replace the existing Unicode conversion functions with UTF conversion functions from js that he relicensed MIT for us. Put the UTF conversion functions in a private but shared code location so that they can be accessed throughout the kernel. Right now we only provide functions to convert between UTF-8 and UTF-16. At some point we should also add functions to convert between UTF-8 and UTF-32 and UTF-16 and UTF-32 but these aren't needed by exfat. Remove the old Unicode conversion functions from exfat as they assumed UCS-2 characters and don't work with UTF-16 used by exfat. Rename most variables with the term length with code unit where code units are intended. The term length, when used, means length in bytes while code units represent either a full 2-byte UTF-16 character or half a 4-byte surrogate pair. diff ebd3bcdb9be2d6a57fc5b3270dcb49a9e1894d11 Wed Feb 12 18:15:18 MST 2014 John Scipione <jscipione@gmail.com> exfat: handle 4-byte UTF-16 surrogate pairs ... in filenames. Replace the existing Unicode conversion functions with UTF conversion functions from js that he relicensed MIT for us. Put the UTF conversion functions in a private but shared code location so that they can be accessed throughout the kernel. Right now we only provide functions to convert between UTF-8 and UTF-16. At some point we should also add functions to convert between UTF-8 and UTF-32 and UTF-16 and UTF-32 but these aren't needed by exfat. Remove the old Unicode conversion functions from exfat as they assumed UCS-2 characters and don't work with UTF-16 used by exfat. Rename most variables with the term length with code unit where code units are intended. The term length, when used, means length in bytes while code units represent either a full 2-byte UTF-16 character or half a 4-byte surrogate pair. e74e90aef91f844d4d3654504cd0776c26a454e5 Wed Feb 09 13:08:48 MST 2011 Jérôme Duval <korli@users.berlios.de> * Implemented a read-only exFAT file system, tested with a 4GB image. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40409 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
H A D | DirectoryIterator.cpp | diff ebd3bcdb Wed Feb 12 18:15:18 MST 2014 John Scipione <jscipione@gmail.com> exfat: handle 4-byte UTF-16 surrogate pairs ... in filenames. Replace the existing Unicode conversion functions with UTF conversion functions from js that he relicensed MIT for us. Put the UTF conversion functions in a private but shared code location so that they can be accessed throughout the kernel. Right now we only provide functions to convert between UTF-8 and UTF-16. At some point we should also add functions to convert between UTF-8 and UTF-32 and UTF-16 and UTF-32 but these aren't needed by exfat. Remove the old Unicode conversion functions from exfat as they assumed UCS-2 characters and don't work with UTF-16 used by exfat. Rename most variables with the term length with code unit where code units are intended. The term length, when used, means length in bytes while code units represent either a full 2-byte UTF-16 character or half a 4-byte surrogate pair. diff ebd3bcdb Wed Feb 12 18:15:18 MST 2014 John Scipione <jscipione@gmail.com> exfat: handle 4-byte UTF-16 surrogate pairs ... in filenames. Replace the existing Unicode conversion functions with UTF conversion functions from js that he relicensed MIT for us. Put the UTF conversion functions in a private but shared code location so that they can be accessed throughout the kernel. Right now we only provide functions to convert between UTF-8 and UTF-16. At some point we should also add functions to convert between UTF-8 and UTF-32 and UTF-16 and UTF-32 but these aren't needed by exfat. Remove the old Unicode conversion functions from exfat as they assumed UCS-2 characters and don't work with UTF-16 used by exfat. Rename most variables with the term length with code unit where code units are intended. The term length, when used, means length in bytes while code units represent either a full 2-byte UTF-16 character or half a 4-byte surrogate pair. diff 5b10d763 Tue Feb 11 11:13:53 MST 2014 John Scipione <jscipione@gmail.com> exfat: use diff structs 4 vol labels and filenames ... and rename the structs to reflect this. * Volume labels contain up to 11 uint16s (11 2-byte UTF-16 characters). * Filenames are packed into 1 to 17 structs of 15 uint16s each (for a total of 255 2-byte UTF-16 characters). * Use 2 different packed structs in the exfat_entry union (same bytes, accessed with different structs) to access these 2 things. * Remove a check that assumed the length returned the number of 2-byte UTF-16 characters, i.e. the number of uint16s the string uses. It doesn't, it returns the number of characters contained in the string which might be 2 or 4-bytes wide. We're doing the conversion wrong for 4-byte UTF-16 characters anyway, more on that later. diff 5b10d763 Tue Feb 11 11:13:53 MST 2014 John Scipione <jscipione@gmail.com> exfat: use diff structs 4 vol labels and filenames ... and rename the structs to reflect this. * Volume labels contain up to 11 uint16s (11 2-byte UTF-16 characters). * Filenames are packed into 1 to 17 structs of 15 uint16s each (for a total of 255 2-byte UTF-16 characters). * Use 2 different packed structs in the exfat_entry union (same bytes, accessed with different structs) to access these 2 things. * Remove a check that assumed the length returned the number of 2-byte UTF-16 characters, i.e. the number of uint16s the string uses. It doesn't, it returns the number of characters contained in the string which might be 2 or 4-bytes wide. We're doing the conversion wrong for 4-byte UTF-16 characters anyway, more on that later. diff 5b10d763 Tue Feb 11 11:13:53 MST 2014 John Scipione <jscipione@gmail.com> exfat: use diff structs 4 vol labels and filenames ... and rename the structs to reflect this. * Volume labels contain up to 11 uint16s (11 2-byte UTF-16 characters). * Filenames are packed into 1 to 17 structs of 15 uint16s each (for a total of 255 2-byte UTF-16 characters). * Use 2 different packed structs in the exfat_entry union (same bytes, accessed with different structs) to access these 2 things. * Remove a check that assumed the length returned the number of 2-byte UTF-16 characters, i.e. the number of uint16s the string uses. It doesn't, it returns the number of characters contained in the string which might be 2 or 4-bytes wide. We're doing the conversion wrong for 4-byte UTF-16 characters anyway, more on that later. diff e74e90ae Wed Feb 09 13:08:48 MST 2011 Jérôme Duval <korli@users.berlios.de> * Implemented a read-only exFAT file system, tested with a 4GB image. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40409 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff ebd3bcdb9be2d6a57fc5b3270dcb49a9e1894d11 Wed Feb 12 18:15:18 MST 2014 John Scipione <jscipione@gmail.com> exfat: handle 4-byte UTF-16 surrogate pairs ... in filenames. Replace the existing Unicode conversion functions with UTF conversion functions from js that he relicensed MIT for us. Put the UTF conversion functions in a private but shared code location so that they can be accessed throughout the kernel. Right now we only provide functions to convert between UTF-8 and UTF-16. At some point we should also add functions to convert between UTF-8 and UTF-32 and UTF-16 and UTF-32 but these aren't needed by exfat. Remove the old Unicode conversion functions from exfat as they assumed UCS-2 characters and don't work with UTF-16 used by exfat. Rename most variables with the term length with code unit where code units are intended. The term length, when used, means length in bytes while code units represent either a full 2-byte UTF-16 character or half a 4-byte surrogate pair. diff ebd3bcdb9be2d6a57fc5b3270dcb49a9e1894d11 Wed Feb 12 18:15:18 MST 2014 John Scipione <jscipione@gmail.com> exfat: handle 4-byte UTF-16 surrogate pairs ... in filenames. Replace the existing Unicode conversion functions with UTF conversion functions from js that he relicensed MIT for us. Put the UTF conversion functions in a private but shared code location so that they can be accessed throughout the kernel. Right now we only provide functions to convert between UTF-8 and UTF-16. At some point we should also add functions to convert between UTF-8 and UTF-32 and UTF-16 and UTF-32 but these aren't needed by exfat. Remove the old Unicode conversion functions from exfat as they assumed UCS-2 characters and don't work with UTF-16 used by exfat. Rename most variables with the term length with code unit where code units are intended. The term length, when used, means length in bytes while code units represent either a full 2-byte UTF-16 character or half a 4-byte surrogate pair. diff 5b10d763d0da84a6f0cb07c610eb25df776273b2 Tue Feb 11 11:13:53 MST 2014 John Scipione <jscipione@gmail.com> exfat: use diff structs 4 vol labels and filenames ... and rename the structs to reflect this. * Volume labels contain up to 11 uint16s (11 2-byte UTF-16 characters). * Filenames are packed into 1 to 17 structs of 15 uint16s each (for a total of 255 2-byte UTF-16 characters). * Use 2 different packed structs in the exfat_entry union (same bytes, accessed with different structs) to access these 2 things. * Remove a check that assumed the length returned the number of 2-byte UTF-16 characters, i.e. the number of uint16s the string uses. It doesn't, it returns the number of characters contained in the string which might be 2 or 4-bytes wide. We're doing the conversion wrong for 4-byte UTF-16 characters anyway, more on that later. diff 5b10d763d0da84a6f0cb07c610eb25df776273b2 Tue Feb 11 11:13:53 MST 2014 John Scipione <jscipione@gmail.com> exfat: use diff structs 4 vol labels and filenames ... and rename the structs to reflect this. * Volume labels contain up to 11 uint16s (11 2-byte UTF-16 characters). * Filenames are packed into 1 to 17 structs of 15 uint16s each (for a total of 255 2-byte UTF-16 characters). * Use 2 different packed structs in the exfat_entry union (same bytes, accessed with different structs) to access these 2 things. * Remove a check that assumed the length returned the number of 2-byte UTF-16 characters, i.e. the number of uint16s the string uses. It doesn't, it returns the number of characters contained in the string which might be 2 or 4-bytes wide. We're doing the conversion wrong for 4-byte UTF-16 characters anyway, more on that later. diff 5b10d763d0da84a6f0cb07c610eb25df776273b2 Tue Feb 11 11:13:53 MST 2014 John Scipione <jscipione@gmail.com> exfat: use diff structs 4 vol labels and filenames ... and rename the structs to reflect this. * Volume labels contain up to 11 uint16s (11 2-byte UTF-16 characters). * Filenames are packed into 1 to 17 structs of 15 uint16s each (for a total of 255 2-byte UTF-16 characters). * Use 2 different packed structs in the exfat_entry union (same bytes, accessed with different structs) to access these 2 things. * Remove a check that assumed the length returned the number of 2-byte UTF-16 characters, i.e. the number of uint16s the string uses. It doesn't, it returns the number of characters contained in the string which might be 2 or 4-bytes wide. We're doing the conversion wrong for 4-byte UTF-16 characters anyway, more on that later. |
/haiku/src/add-ons/kernel/drivers/network/wwan/ | ||
H A D | Jamfile | diff 4e0a6a83 Sun Jul 30 12:40:42 MDT 2017 Augustin Cavalier <waddlesplash@gmail.com> wwan: Fixup last commit. (Forgot to comment this out.) diff f78f38a5 Fri Sep 02 10:27:35 MDT 2011 Alexander von Gluck IV <kallisti5@unixzen.com> * rename wimax driver directory to wwan to be more generic * given the rise of other 4G wwan technology such as lte, this seems cleaner and better matches wlan directory for wifi. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42707 a95241bf-73f2-0310-859d-f6bbb57e9c96 f78f38a51c1b42bf25bc6fa1c35006263f6589fb Fri Sep 02 10:27:35 MDT 2011 Alexander von Gluck IV <kallisti5@unixzen.com> * rename wimax driver directory to wwan to be more generic * given the rise of other 4G wwan technology such as lte, this seems cleaner and better matches wlan directory for wifi. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42707 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
/haiku/src/add-ons/kernel/bus_managers/acpi/acpica/include/platform/ | ||
H A D | achaiku.h | diff f2acc47f Wed Dec 06 10:38:28 MST 2023 Jérôme Duval <jerome.duval@gmail.com> acpi: update AcpiOsAcquireGlobalLock and AcpiOsReleaseGlobalLock implementations from FreeBSD. Because the argument wasn't volatile, the compiler wasn't considerung reading the lock content. * fix the acquire and release loops: The loop could be exited when any new values were read. Instead the return value should be checked against the old value. Old x86 gcc2 asm loop in AcpiOsAcquireGlobalLock: 11660: 89 c8 mov %ecx,%eax 11662: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11666: 39 0a cmp %ecx,(%edx) 11668: 74 f6 je 11660 <AcpiOsAcquireGlobalLock+0x20> New x86 gcc13 asm loop in AcpiOsAcquireGlobalLock: 4d58: 8b 11 mov (%ecx),%edx 4d5a: 89 d0 mov %edx,%eax 4d5c: 89 d3 mov %edx,%ebx 4d5e: 83 e0 fc and $0xfffffffc,%eax 4d61: 83 cb 03 or $0x3,%ebx 4d64: f6 c2 02 test $0x2,%dl 4d67: 75 05 jne 4d6e <AcpiOsAcquireGlobalLock+0x1e> 4d69: 83 c8 02 or $0x2,%eax 4d6c: 89 c3 mov %eax,%ebx 4d6e: 89 d0 mov %edx,%eax 4d70: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d74: 75 e2 jne 4d58 <AcpiOsAcquireGlobalLock+0x8> Old x86 gcc2 asm loop in AcpiOsReleaseGlobalLock: 11690: 89 c8 mov %ecx,%eax 11692: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11696: 39 0a cmp %ecx,(%edx) 11698: 74 f6 je 11690 <AcpiOsReleaseGlobalLock+0x10> New x86 gcc13 asm loop in AcpiOsReleaseGlobalLock: 4d88: 8b 11 mov (%ecx),%edx 4d8a: 89 d3 mov %edx,%ebx 4d8c: 89 d0 mov %edx,%eax 4d8e: 83 e3 fc and $0xfffffffc,%ebx 4d91: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d95: 75 f1 jne 4d88 <AcpiOsReleaseGlobalLock+0x8> Change-Id: Ia55ba8666efe8b5c198a01db100b4747b72df4a0 Reviewed-on: https://review.haiku-os.org/c/haiku/+/7185 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff f2acc47f Wed Dec 06 10:38:28 MST 2023 Jérôme Duval <jerome.duval@gmail.com> acpi: update AcpiOsAcquireGlobalLock and AcpiOsReleaseGlobalLock implementations from FreeBSD. Because the argument wasn't volatile, the compiler wasn't considerung reading the lock content. * fix the acquire and release loops: The loop could be exited when any new values were read. Instead the return value should be checked against the old value. Old x86 gcc2 asm loop in AcpiOsAcquireGlobalLock: 11660: 89 c8 mov %ecx,%eax 11662: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11666: 39 0a cmp %ecx,(%edx) 11668: 74 f6 je 11660 <AcpiOsAcquireGlobalLock+0x20> New x86 gcc13 asm loop in AcpiOsAcquireGlobalLock: 4d58: 8b 11 mov (%ecx),%edx 4d5a: 89 d0 mov %edx,%eax 4d5c: 89 d3 mov %edx,%ebx 4d5e: 83 e0 fc and $0xfffffffc,%eax 4d61: 83 cb 03 or $0x3,%ebx 4d64: f6 c2 02 test $0x2,%dl 4d67: 75 05 jne 4d6e <AcpiOsAcquireGlobalLock+0x1e> 4d69: 83 c8 02 or $0x2,%eax 4d6c: 89 c3 mov %eax,%ebx 4d6e: 89 d0 mov %edx,%eax 4d70: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d74: 75 e2 jne 4d58 <AcpiOsAcquireGlobalLock+0x8> Old x86 gcc2 asm loop in AcpiOsReleaseGlobalLock: 11690: 89 c8 mov %ecx,%eax 11692: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11696: 39 0a cmp %ecx,(%edx) 11698: 74 f6 je 11690 <AcpiOsReleaseGlobalLock+0x10> New x86 gcc13 asm loop in AcpiOsReleaseGlobalLock: 4d88: 8b 11 mov (%ecx),%edx 4d8a: 89 d3 mov %edx,%ebx 4d8c: 89 d0 mov %edx,%eax 4d8e: 83 e3 fc and $0xfffffffc,%ebx 4d91: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d95: 75 f1 jne 4d88 <AcpiOsReleaseGlobalLock+0x8> Change-Id: Ia55ba8666efe8b5c198a01db100b4747b72df4a0 Reviewed-on: https://review.haiku-os.org/c/haiku/+/7185 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff f2acc47f Wed Dec 06 10:38:28 MST 2023 Jérôme Duval <jerome.duval@gmail.com> acpi: update AcpiOsAcquireGlobalLock and AcpiOsReleaseGlobalLock implementations from FreeBSD. Because the argument wasn't volatile, the compiler wasn't considerung reading the lock content. * fix the acquire and release loops: The loop could be exited when any new values were read. Instead the return value should be checked against the old value. Old x86 gcc2 asm loop in AcpiOsAcquireGlobalLock: 11660: 89 c8 mov %ecx,%eax 11662: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11666: 39 0a cmp %ecx,(%edx) 11668: 74 f6 je 11660 <AcpiOsAcquireGlobalLock+0x20> New x86 gcc13 asm loop in AcpiOsAcquireGlobalLock: 4d58: 8b 11 mov (%ecx),%edx 4d5a: 89 d0 mov %edx,%eax 4d5c: 89 d3 mov %edx,%ebx 4d5e: 83 e0 fc and $0xfffffffc,%eax 4d61: 83 cb 03 or $0x3,%ebx 4d64: f6 c2 02 test $0x2,%dl 4d67: 75 05 jne 4d6e <AcpiOsAcquireGlobalLock+0x1e> 4d69: 83 c8 02 or $0x2,%eax 4d6c: 89 c3 mov %eax,%ebx 4d6e: 89 d0 mov %edx,%eax 4d70: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d74: 75 e2 jne 4d58 <AcpiOsAcquireGlobalLock+0x8> Old x86 gcc2 asm loop in AcpiOsReleaseGlobalLock: 11690: 89 c8 mov %ecx,%eax 11692: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11696: 39 0a cmp %ecx,(%edx) 11698: 74 f6 je 11690 <AcpiOsReleaseGlobalLock+0x10> New x86 gcc13 asm loop in AcpiOsReleaseGlobalLock: 4d88: 8b 11 mov (%ecx),%edx 4d8a: 89 d3 mov %edx,%ebx 4d8c: 89 d0 mov %edx,%eax 4d8e: 83 e3 fc and $0xfffffffc,%ebx 4d91: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d95: 75 f1 jne 4d88 <AcpiOsReleaseGlobalLock+0x8> Change-Id: Ia55ba8666efe8b5c198a01db100b4747b72df4a0 Reviewed-on: https://review.haiku-os.org/c/haiku/+/7185 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff f2acc47f Wed Dec 06 10:38:28 MST 2023 Jérôme Duval <jerome.duval@gmail.com> acpi: update AcpiOsAcquireGlobalLock and AcpiOsReleaseGlobalLock implementations from FreeBSD. Because the argument wasn't volatile, the compiler wasn't considerung reading the lock content. * fix the acquire and release loops: The loop could be exited when any new values were read. Instead the return value should be checked against the old value. Old x86 gcc2 asm loop in AcpiOsAcquireGlobalLock: 11660: 89 c8 mov %ecx,%eax 11662: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11666: 39 0a cmp %ecx,(%edx) 11668: 74 f6 je 11660 <AcpiOsAcquireGlobalLock+0x20> New x86 gcc13 asm loop in AcpiOsAcquireGlobalLock: 4d58: 8b 11 mov (%ecx),%edx 4d5a: 89 d0 mov %edx,%eax 4d5c: 89 d3 mov %edx,%ebx 4d5e: 83 e0 fc and $0xfffffffc,%eax 4d61: 83 cb 03 or $0x3,%ebx 4d64: f6 c2 02 test $0x2,%dl 4d67: 75 05 jne 4d6e <AcpiOsAcquireGlobalLock+0x1e> 4d69: 83 c8 02 or $0x2,%eax 4d6c: 89 c3 mov %eax,%ebx 4d6e: 89 d0 mov %edx,%eax 4d70: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d74: 75 e2 jne 4d58 <AcpiOsAcquireGlobalLock+0x8> Old x86 gcc2 asm loop in AcpiOsReleaseGlobalLock: 11690: 89 c8 mov %ecx,%eax 11692: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11696: 39 0a cmp %ecx,(%edx) 11698: 74 f6 je 11690 <AcpiOsReleaseGlobalLock+0x10> New x86 gcc13 asm loop in AcpiOsReleaseGlobalLock: 4d88: 8b 11 mov (%ecx),%edx 4d8a: 89 d3 mov %edx,%ebx 4d8c: 89 d0 mov %edx,%eax 4d8e: 83 e3 fc and $0xfffffffc,%ebx 4d91: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d95: 75 f1 jne 4d88 <AcpiOsReleaseGlobalLock+0x8> Change-Id: Ia55ba8666efe8b5c198a01db100b4747b72df4a0 Reviewed-on: https://review.haiku-os.org/c/haiku/+/7185 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff f2acc47f Wed Dec 06 10:38:28 MST 2023 Jérôme Duval <jerome.duval@gmail.com> acpi: update AcpiOsAcquireGlobalLock and AcpiOsReleaseGlobalLock implementations from FreeBSD. Because the argument wasn't volatile, the compiler wasn't considerung reading the lock content. * fix the acquire and release loops: The loop could be exited when any new values were read. Instead the return value should be checked against the old value. Old x86 gcc2 asm loop in AcpiOsAcquireGlobalLock: 11660: 89 c8 mov %ecx,%eax 11662: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11666: 39 0a cmp %ecx,(%edx) 11668: 74 f6 je 11660 <AcpiOsAcquireGlobalLock+0x20> New x86 gcc13 asm loop in AcpiOsAcquireGlobalLock: 4d58: 8b 11 mov (%ecx),%edx 4d5a: 89 d0 mov %edx,%eax 4d5c: 89 d3 mov %edx,%ebx 4d5e: 83 e0 fc and $0xfffffffc,%eax 4d61: 83 cb 03 or $0x3,%ebx 4d64: f6 c2 02 test $0x2,%dl 4d67: 75 05 jne 4d6e <AcpiOsAcquireGlobalLock+0x1e> 4d69: 83 c8 02 or $0x2,%eax 4d6c: 89 c3 mov %eax,%ebx 4d6e: 89 d0 mov %edx,%eax 4d70: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d74: 75 e2 jne 4d58 <AcpiOsAcquireGlobalLock+0x8> Old x86 gcc2 asm loop in AcpiOsReleaseGlobalLock: 11690: 89 c8 mov %ecx,%eax 11692: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11696: 39 0a cmp %ecx,(%edx) 11698: 74 f6 je 11690 <AcpiOsReleaseGlobalLock+0x10> New x86 gcc13 asm loop in AcpiOsReleaseGlobalLock: 4d88: 8b 11 mov (%ecx),%edx 4d8a: 89 d3 mov %edx,%ebx 4d8c: 89 d0 mov %edx,%eax 4d8e: 83 e3 fc and $0xfffffffc,%ebx 4d91: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d95: 75 f1 jne 4d88 <AcpiOsReleaseGlobalLock+0x8> Change-Id: Ia55ba8666efe8b5c198a01db100b4747b72df4a0 Reviewed-on: https://review.haiku-os.org/c/haiku/+/7185 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff f2acc47f Wed Dec 06 10:38:28 MST 2023 Jérôme Duval <jerome.duval@gmail.com> acpi: update AcpiOsAcquireGlobalLock and AcpiOsReleaseGlobalLock implementations from FreeBSD. Because the argument wasn't volatile, the compiler wasn't considerung reading the lock content. * fix the acquire and release loops: The loop could be exited when any new values were read. Instead the return value should be checked against the old value. Old x86 gcc2 asm loop in AcpiOsAcquireGlobalLock: 11660: 89 c8 mov %ecx,%eax 11662: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11666: 39 0a cmp %ecx,(%edx) 11668: 74 f6 je 11660 <AcpiOsAcquireGlobalLock+0x20> New x86 gcc13 asm loop in AcpiOsAcquireGlobalLock: 4d58: 8b 11 mov (%ecx),%edx 4d5a: 89 d0 mov %edx,%eax 4d5c: 89 d3 mov %edx,%ebx 4d5e: 83 e0 fc and $0xfffffffc,%eax 4d61: 83 cb 03 or $0x3,%ebx 4d64: f6 c2 02 test $0x2,%dl 4d67: 75 05 jne 4d6e <AcpiOsAcquireGlobalLock+0x1e> 4d69: 83 c8 02 or $0x2,%eax 4d6c: 89 c3 mov %eax,%ebx 4d6e: 89 d0 mov %edx,%eax 4d70: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d74: 75 e2 jne 4d58 <AcpiOsAcquireGlobalLock+0x8> Old x86 gcc2 asm loop in AcpiOsReleaseGlobalLock: 11690: 89 c8 mov %ecx,%eax 11692: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11696: 39 0a cmp %ecx,(%edx) 11698: 74 f6 je 11690 <AcpiOsReleaseGlobalLock+0x10> New x86 gcc13 asm loop in AcpiOsReleaseGlobalLock: 4d88: 8b 11 mov (%ecx),%edx 4d8a: 89 d3 mov %edx,%ebx 4d8c: 89 d0 mov %edx,%eax 4d8e: 83 e3 fc and $0xfffffffc,%ebx 4d91: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d95: 75 f1 jne 4d88 <AcpiOsReleaseGlobalLock+0x8> Change-Id: Ia55ba8666efe8b5c198a01db100b4747b72df4a0 Reviewed-on: https://review.haiku-os.org/c/haiku/+/7185 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff f2acc47f Wed Dec 06 10:38:28 MST 2023 Jérôme Duval <jerome.duval@gmail.com> acpi: update AcpiOsAcquireGlobalLock and AcpiOsReleaseGlobalLock implementations from FreeBSD. Because the argument wasn't volatile, the compiler wasn't considerung reading the lock content. * fix the acquire and release loops: The loop could be exited when any new values were read. Instead the return value should be checked against the old value. Old x86 gcc2 asm loop in AcpiOsAcquireGlobalLock: 11660: 89 c8 mov %ecx,%eax 11662: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11666: 39 0a cmp %ecx,(%edx) 11668: 74 f6 je 11660 <AcpiOsAcquireGlobalLock+0x20> New x86 gcc13 asm loop in AcpiOsAcquireGlobalLock: 4d58: 8b 11 mov (%ecx),%edx 4d5a: 89 d0 mov %edx,%eax 4d5c: 89 d3 mov %edx,%ebx 4d5e: 83 e0 fc and $0xfffffffc,%eax 4d61: 83 cb 03 or $0x3,%ebx 4d64: f6 c2 02 test $0x2,%dl 4d67: 75 05 jne 4d6e <AcpiOsAcquireGlobalLock+0x1e> 4d69: 83 c8 02 or $0x2,%eax 4d6c: 89 c3 mov %eax,%ebx 4d6e: 89 d0 mov %edx,%eax 4d70: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d74: 75 e2 jne 4d58 <AcpiOsAcquireGlobalLock+0x8> Old x86 gcc2 asm loop in AcpiOsReleaseGlobalLock: 11690: 89 c8 mov %ecx,%eax 11692: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11696: 39 0a cmp %ecx,(%edx) 11698: 74 f6 je 11690 <AcpiOsReleaseGlobalLock+0x10> New x86 gcc13 asm loop in AcpiOsReleaseGlobalLock: 4d88: 8b 11 mov (%ecx),%edx 4d8a: 89 d3 mov %edx,%ebx 4d8c: 89 d0 mov %edx,%eax 4d8e: 83 e3 fc and $0xfffffffc,%ebx 4d91: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d95: 75 f1 jne 4d88 <AcpiOsReleaseGlobalLock+0x8> Change-Id: Ia55ba8666efe8b5c198a01db100b4747b72df4a0 Reviewed-on: https://review.haiku-os.org/c/haiku/+/7185 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff f2acc47f Wed Dec 06 10:38:28 MST 2023 Jérôme Duval <jerome.duval@gmail.com> acpi: update AcpiOsAcquireGlobalLock and AcpiOsReleaseGlobalLock implementations from FreeBSD. Because the argument wasn't volatile, the compiler wasn't considerung reading the lock content. * fix the acquire and release loops: The loop could be exited when any new values were read. Instead the return value should be checked against the old value. Old x86 gcc2 asm loop in AcpiOsAcquireGlobalLock: 11660: 89 c8 mov %ecx,%eax 11662: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11666: 39 0a cmp %ecx,(%edx) 11668: 74 f6 je 11660 <AcpiOsAcquireGlobalLock+0x20> New x86 gcc13 asm loop in AcpiOsAcquireGlobalLock: 4d58: 8b 11 mov (%ecx),%edx 4d5a: 89 d0 mov %edx,%eax 4d5c: 89 d3 mov %edx,%ebx 4d5e: 83 e0 fc and $0xfffffffc,%eax 4d61: 83 cb 03 or $0x3,%ebx 4d64: f6 c2 02 test $0x2,%dl 4d67: 75 05 jne 4d6e <AcpiOsAcquireGlobalLock+0x1e> 4d69: 83 c8 02 or $0x2,%eax 4d6c: 89 c3 mov %eax,%ebx 4d6e: 89 d0 mov %edx,%eax 4d70: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d74: 75 e2 jne 4d58 <AcpiOsAcquireGlobalLock+0x8> Old x86 gcc2 asm loop in AcpiOsReleaseGlobalLock: 11690: 89 c8 mov %ecx,%eax 11692: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11696: 39 0a cmp %ecx,(%edx) 11698: 74 f6 je 11690 <AcpiOsReleaseGlobalLock+0x10> New x86 gcc13 asm loop in AcpiOsReleaseGlobalLock: 4d88: 8b 11 mov (%ecx),%edx 4d8a: 89 d3 mov %edx,%ebx 4d8c: 89 d0 mov %edx,%eax 4d8e: 83 e3 fc and $0xfffffffc,%ebx 4d91: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d95: 75 f1 jne 4d88 <AcpiOsReleaseGlobalLock+0x8> Change-Id: Ia55ba8666efe8b5c198a01db100b4747b72df4a0 Reviewed-on: https://review.haiku-os.org/c/haiku/+/7185 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff f2acc47f Wed Dec 06 10:38:28 MST 2023 Jérôme Duval <jerome.duval@gmail.com> acpi: update AcpiOsAcquireGlobalLock and AcpiOsReleaseGlobalLock implementations from FreeBSD. Because the argument wasn't volatile, the compiler wasn't considerung reading the lock content. * fix the acquire and release loops: The loop could be exited when any new values were read. Instead the return value should be checked against the old value. Old x86 gcc2 asm loop in AcpiOsAcquireGlobalLock: 11660: 89 c8 mov %ecx,%eax 11662: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11666: 39 0a cmp %ecx,(%edx) 11668: 74 f6 je 11660 <AcpiOsAcquireGlobalLock+0x20> New x86 gcc13 asm loop in AcpiOsAcquireGlobalLock: 4d58: 8b 11 mov (%ecx),%edx 4d5a: 89 d0 mov %edx,%eax 4d5c: 89 d3 mov %edx,%ebx 4d5e: 83 e0 fc and $0xfffffffc,%eax 4d61: 83 cb 03 or $0x3,%ebx 4d64: f6 c2 02 test $0x2,%dl 4d67: 75 05 jne 4d6e <AcpiOsAcquireGlobalLock+0x1e> 4d69: 83 c8 02 or $0x2,%eax 4d6c: 89 c3 mov %eax,%ebx 4d6e: 89 d0 mov %edx,%eax 4d70: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d74: 75 e2 jne 4d58 <AcpiOsAcquireGlobalLock+0x8> Old x86 gcc2 asm loop in AcpiOsReleaseGlobalLock: 11690: 89 c8 mov %ecx,%eax 11692: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11696: 39 0a cmp %ecx,(%edx) 11698: 74 f6 je 11690 <AcpiOsReleaseGlobalLock+0x10> New x86 gcc13 asm loop in AcpiOsReleaseGlobalLock: 4d88: 8b 11 mov (%ecx),%edx 4d8a: 89 d3 mov %edx,%ebx 4d8c: 89 d0 mov %edx,%eax 4d8e: 83 e3 fc and $0xfffffffc,%ebx 4d91: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d95: 75 f1 jne 4d88 <AcpiOsReleaseGlobalLock+0x8> Change-Id: Ia55ba8666efe8b5c198a01db100b4747b72df4a0 Reviewed-on: https://review.haiku-os.org/c/haiku/+/7185 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff f2acc47f Wed Dec 06 10:38:28 MST 2023 Jérôme Duval <jerome.duval@gmail.com> acpi: update AcpiOsAcquireGlobalLock and AcpiOsReleaseGlobalLock implementations from FreeBSD. Because the argument wasn't volatile, the compiler wasn't considerung reading the lock content. * fix the acquire and release loops: The loop could be exited when any new values were read. Instead the return value should be checked against the old value. Old x86 gcc2 asm loop in AcpiOsAcquireGlobalLock: 11660: 89 c8 mov %ecx,%eax 11662: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11666: 39 0a cmp %ecx,(%edx) 11668: 74 f6 je 11660 <AcpiOsAcquireGlobalLock+0x20> New x86 gcc13 asm loop in AcpiOsAcquireGlobalLock: 4d58: 8b 11 mov (%ecx),%edx 4d5a: 89 d0 mov %edx,%eax 4d5c: 89 d3 mov %edx,%ebx 4d5e: 83 e0 fc and $0xfffffffc,%eax 4d61: 83 cb 03 or $0x3,%ebx 4d64: f6 c2 02 test $0x2,%dl 4d67: 75 05 jne 4d6e <AcpiOsAcquireGlobalLock+0x1e> 4d69: 83 c8 02 or $0x2,%eax 4d6c: 89 c3 mov %eax,%ebx 4d6e: 89 d0 mov %edx,%eax 4d70: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d74: 75 e2 jne 4d58 <AcpiOsAcquireGlobalLock+0x8> Old x86 gcc2 asm loop in AcpiOsReleaseGlobalLock: 11690: 89 c8 mov %ecx,%eax 11692: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11696: 39 0a cmp %ecx,(%edx) 11698: 74 f6 je 11690 <AcpiOsReleaseGlobalLock+0x10> New x86 gcc13 asm loop in AcpiOsReleaseGlobalLock: 4d88: 8b 11 mov (%ecx),%edx 4d8a: 89 d3 mov %edx,%ebx 4d8c: 89 d0 mov %edx,%eax 4d8e: 83 e3 fc and $0xfffffffc,%ebx 4d91: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d95: 75 f1 jne 4d88 <AcpiOsReleaseGlobalLock+0x8> Change-Id: Ia55ba8666efe8b5c198a01db100b4747b72df4a0 Reviewed-on: https://review.haiku-os.org/c/haiku/+/7185 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff f2acc47f Wed Dec 06 10:38:28 MST 2023 Jérôme Duval <jerome.duval@gmail.com> acpi: update AcpiOsAcquireGlobalLock and AcpiOsReleaseGlobalLock implementations from FreeBSD. Because the argument wasn't volatile, the compiler wasn't considerung reading the lock content. * fix the acquire and release loops: The loop could be exited when any new values were read. Instead the return value should be checked against the old value. Old x86 gcc2 asm loop in AcpiOsAcquireGlobalLock: 11660: 89 c8 mov %ecx,%eax 11662: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11666: 39 0a cmp %ecx,(%edx) 11668: 74 f6 je 11660 <AcpiOsAcquireGlobalLock+0x20> New x86 gcc13 asm loop in AcpiOsAcquireGlobalLock: 4d58: 8b 11 mov (%ecx),%edx 4d5a: 89 d0 mov %edx,%eax 4d5c: 89 d3 mov %edx,%ebx 4d5e: 83 e0 fc and $0xfffffffc,%eax 4d61: 83 cb 03 or $0x3,%ebx 4d64: f6 c2 02 test $0x2,%dl 4d67: 75 05 jne 4d6e <AcpiOsAcquireGlobalLock+0x1e> 4d69: 83 c8 02 or $0x2,%eax 4d6c: 89 c3 mov %eax,%ebx 4d6e: 89 d0 mov %edx,%eax 4d70: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d74: 75 e2 jne 4d58 <AcpiOsAcquireGlobalLock+0x8> Old x86 gcc2 asm loop in AcpiOsReleaseGlobalLock: 11690: 89 c8 mov %ecx,%eax 11692: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11696: 39 0a cmp %ecx,(%edx) 11698: 74 f6 je 11690 <AcpiOsReleaseGlobalLock+0x10> New x86 gcc13 asm loop in AcpiOsReleaseGlobalLock: 4d88: 8b 11 mov (%ecx),%edx 4d8a: 89 d3 mov %edx,%ebx 4d8c: 89 d0 mov %edx,%eax 4d8e: 83 e3 fc and $0xfffffffc,%ebx 4d91: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d95: 75 f1 jne 4d88 <AcpiOsReleaseGlobalLock+0x8> Change-Id: Ia55ba8666efe8b5c198a01db100b4747b72df4a0 Reviewed-on: https://review.haiku-os.org/c/haiku/+/7185 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff f2acc47f Wed Dec 06 10:38:28 MST 2023 Jérôme Duval <jerome.duval@gmail.com> acpi: update AcpiOsAcquireGlobalLock and AcpiOsReleaseGlobalLock implementations from FreeBSD. Because the argument wasn't volatile, the compiler wasn't considerung reading the lock content. * fix the acquire and release loops: The loop could be exited when any new values were read. Instead the return value should be checked against the old value. Old x86 gcc2 asm loop in AcpiOsAcquireGlobalLock: 11660: 89 c8 mov %ecx,%eax 11662: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11666: 39 0a cmp %ecx,(%edx) 11668: 74 f6 je 11660 <AcpiOsAcquireGlobalLock+0x20> New x86 gcc13 asm loop in AcpiOsAcquireGlobalLock: 4d58: 8b 11 mov (%ecx),%edx 4d5a: 89 d0 mov %edx,%eax 4d5c: 89 d3 mov %edx,%ebx 4d5e: 83 e0 fc and $0xfffffffc,%eax 4d61: 83 cb 03 or $0x3,%ebx 4d64: f6 c2 02 test $0x2,%dl 4d67: 75 05 jne 4d6e <AcpiOsAcquireGlobalLock+0x1e> 4d69: 83 c8 02 or $0x2,%eax 4d6c: 89 c3 mov %eax,%ebx 4d6e: 89 d0 mov %edx,%eax 4d70: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d74: 75 e2 jne 4d58 <AcpiOsAcquireGlobalLock+0x8> Old x86 gcc2 asm loop in AcpiOsReleaseGlobalLock: 11690: 89 c8 mov %ecx,%eax 11692: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11696: 39 0a cmp %ecx,(%edx) 11698: 74 f6 je 11690 <AcpiOsReleaseGlobalLock+0x10> New x86 gcc13 asm loop in AcpiOsReleaseGlobalLock: 4d88: 8b 11 mov (%ecx),%edx 4d8a: 89 d3 mov %edx,%ebx 4d8c: 89 d0 mov %edx,%eax 4d8e: 83 e3 fc and $0xfffffffc,%ebx 4d91: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d95: 75 f1 jne 4d88 <AcpiOsReleaseGlobalLock+0x8> Change-Id: Ia55ba8666efe8b5c198a01db100b4747b72df4a0 Reviewed-on: https://review.haiku-os.org/c/haiku/+/7185 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff f2acc47f Wed Dec 06 10:38:28 MST 2023 Jérôme Duval <jerome.duval@gmail.com> acpi: update AcpiOsAcquireGlobalLock and AcpiOsReleaseGlobalLock implementations from FreeBSD. Because the argument wasn't volatile, the compiler wasn't considerung reading the lock content. * fix the acquire and release loops: The loop could be exited when any new values were read. Instead the return value should be checked against the old value. Old x86 gcc2 asm loop in AcpiOsAcquireGlobalLock: 11660: 89 c8 mov %ecx,%eax 11662: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11666: 39 0a cmp %ecx,(%edx) 11668: 74 f6 je 11660 <AcpiOsAcquireGlobalLock+0x20> New x86 gcc13 asm loop in AcpiOsAcquireGlobalLock: 4d58: 8b 11 mov (%ecx),%edx 4d5a: 89 d0 mov %edx,%eax 4d5c: 89 d3 mov %edx,%ebx 4d5e: 83 e0 fc and $0xfffffffc,%eax 4d61: 83 cb 03 or $0x3,%ebx 4d64: f6 c2 02 test $0x2,%dl 4d67: 75 05 jne 4d6e <AcpiOsAcquireGlobalLock+0x1e> 4d69: 83 c8 02 or $0x2,%eax 4d6c: 89 c3 mov %eax,%ebx 4d6e: 89 d0 mov %edx,%eax 4d70: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d74: 75 e2 jne 4d58 <AcpiOsAcquireGlobalLock+0x8> Old x86 gcc2 asm loop in AcpiOsReleaseGlobalLock: 11690: 89 c8 mov %ecx,%eax 11692: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11696: 39 0a cmp %ecx,(%edx) 11698: 74 f6 je 11690 <AcpiOsReleaseGlobalLock+0x10> New x86 gcc13 asm loop in AcpiOsReleaseGlobalLock: 4d88: 8b 11 mov (%ecx),%edx 4d8a: 89 d3 mov %edx,%ebx 4d8c: 89 d0 mov %edx,%eax 4d8e: 83 e3 fc and $0xfffffffc,%ebx 4d91: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d95: 75 f1 jne 4d88 <AcpiOsReleaseGlobalLock+0x8> Change-Id: Ia55ba8666efe8b5c198a01db100b4747b72df4a0 Reviewed-on: https://review.haiku-os.org/c/haiku/+/7185 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff f2acc47f Wed Dec 06 10:38:28 MST 2023 Jérôme Duval <jerome.duval@gmail.com> acpi: update AcpiOsAcquireGlobalLock and AcpiOsReleaseGlobalLock implementations from FreeBSD. Because the argument wasn't volatile, the compiler wasn't considerung reading the lock content. * fix the acquire and release loops: The loop could be exited when any new values were read. Instead the return value should be checked against the old value. Old x86 gcc2 asm loop in AcpiOsAcquireGlobalLock: 11660: 89 c8 mov %ecx,%eax 11662: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11666: 39 0a cmp %ecx,(%edx) 11668: 74 f6 je 11660 <AcpiOsAcquireGlobalLock+0x20> New x86 gcc13 asm loop in AcpiOsAcquireGlobalLock: 4d58: 8b 11 mov (%ecx),%edx 4d5a: 89 d0 mov %edx,%eax 4d5c: 89 d3 mov %edx,%ebx 4d5e: 83 e0 fc and $0xfffffffc,%eax 4d61: 83 cb 03 or $0x3,%ebx 4d64: f6 c2 02 test $0x2,%dl 4d67: 75 05 jne 4d6e <AcpiOsAcquireGlobalLock+0x1e> 4d69: 83 c8 02 or $0x2,%eax 4d6c: 89 c3 mov %eax,%ebx 4d6e: 89 d0 mov %edx,%eax 4d70: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d74: 75 e2 jne 4d58 <AcpiOsAcquireGlobalLock+0x8> Old x86 gcc2 asm loop in AcpiOsReleaseGlobalLock: 11690: 89 c8 mov %ecx,%eax 11692: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11696: 39 0a cmp %ecx,(%edx) 11698: 74 f6 je 11690 <AcpiOsReleaseGlobalLock+0x10> New x86 gcc13 asm loop in AcpiOsReleaseGlobalLock: 4d88: 8b 11 mov (%ecx),%edx 4d8a: 89 d3 mov %edx,%ebx 4d8c: 89 d0 mov %edx,%eax 4d8e: 83 e3 fc and $0xfffffffc,%ebx 4d91: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d95: 75 f1 jne 4d88 <AcpiOsReleaseGlobalLock+0x8> Change-Id: Ia55ba8666efe8b5c198a01db100b4747b72df4a0 Reviewed-on: https://review.haiku-os.org/c/haiku/+/7185 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff f2acc47f Wed Dec 06 10:38:28 MST 2023 Jérôme Duval <jerome.duval@gmail.com> acpi: update AcpiOsAcquireGlobalLock and AcpiOsReleaseGlobalLock implementations from FreeBSD. Because the argument wasn't volatile, the compiler wasn't considerung reading the lock content. * fix the acquire and release loops: The loop could be exited when any new values were read. Instead the return value should be checked against the old value. Old x86 gcc2 asm loop in AcpiOsAcquireGlobalLock: 11660: 89 c8 mov %ecx,%eax 11662: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11666: 39 0a cmp %ecx,(%edx) 11668: 74 f6 je 11660 <AcpiOsAcquireGlobalLock+0x20> New x86 gcc13 asm loop in AcpiOsAcquireGlobalLock: 4d58: 8b 11 mov (%ecx),%edx 4d5a: 89 d0 mov %edx,%eax 4d5c: 89 d3 mov %edx,%ebx 4d5e: 83 e0 fc and $0xfffffffc,%eax 4d61: 83 cb 03 or $0x3,%ebx 4d64: f6 c2 02 test $0x2,%dl 4d67: 75 05 jne 4d6e <AcpiOsAcquireGlobalLock+0x1e> 4d69: 83 c8 02 or $0x2,%eax 4d6c: 89 c3 mov %eax,%ebx 4d6e: 89 d0 mov %edx,%eax 4d70: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d74: 75 e2 jne 4d58 <AcpiOsAcquireGlobalLock+0x8> Old x86 gcc2 asm loop in AcpiOsReleaseGlobalLock: 11690: 89 c8 mov %ecx,%eax 11692: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11696: 39 0a cmp %ecx,(%edx) 11698: 74 f6 je 11690 <AcpiOsReleaseGlobalLock+0x10> New x86 gcc13 asm loop in AcpiOsReleaseGlobalLock: 4d88: 8b 11 mov (%ecx),%edx 4d8a: 89 d3 mov %edx,%ebx 4d8c: 89 d0 mov %edx,%eax 4d8e: 83 e3 fc and $0xfffffffc,%ebx 4d91: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d95: 75 f1 jne 4d88 <AcpiOsReleaseGlobalLock+0x8> Change-Id: Ia55ba8666efe8b5c198a01db100b4747b72df4a0 Reviewed-on: https://review.haiku-os.org/c/haiku/+/7185 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff f2acc47f Wed Dec 06 10:38:28 MST 2023 Jérôme Duval <jerome.duval@gmail.com> acpi: update AcpiOsAcquireGlobalLock and AcpiOsReleaseGlobalLock implementations from FreeBSD. Because the argument wasn't volatile, the compiler wasn't considerung reading the lock content. * fix the acquire and release loops: The loop could be exited when any new values were read. Instead the return value should be checked against the old value. Old x86 gcc2 asm loop in AcpiOsAcquireGlobalLock: 11660: 89 c8 mov %ecx,%eax 11662: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11666: 39 0a cmp %ecx,(%edx) 11668: 74 f6 je 11660 <AcpiOsAcquireGlobalLock+0x20> New x86 gcc13 asm loop in AcpiOsAcquireGlobalLock: 4d58: 8b 11 mov (%ecx),%edx 4d5a: 89 d0 mov %edx,%eax 4d5c: 89 d3 mov %edx,%ebx 4d5e: 83 e0 fc and $0xfffffffc,%eax 4d61: 83 cb 03 or $0x3,%ebx 4d64: f6 c2 02 test $0x2,%dl 4d67: 75 05 jne 4d6e <AcpiOsAcquireGlobalLock+0x1e> 4d69: 83 c8 02 or $0x2,%eax 4d6c: 89 c3 mov %eax,%ebx 4d6e: 89 d0 mov %edx,%eax 4d70: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d74: 75 e2 jne 4d58 <AcpiOsAcquireGlobalLock+0x8> Old x86 gcc2 asm loop in AcpiOsReleaseGlobalLock: 11690: 89 c8 mov %ecx,%eax 11692: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11696: 39 0a cmp %ecx,(%edx) 11698: 74 f6 je 11690 <AcpiOsReleaseGlobalLock+0x10> New x86 gcc13 asm loop in AcpiOsReleaseGlobalLock: 4d88: 8b 11 mov (%ecx),%edx 4d8a: 89 d3 mov %edx,%ebx 4d8c: 89 d0 mov %edx,%eax 4d8e: 83 e3 fc and $0xfffffffc,%ebx 4d91: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d95: 75 f1 jne 4d88 <AcpiOsReleaseGlobalLock+0x8> Change-Id: Ia55ba8666efe8b5c198a01db100b4747b72df4a0 Reviewed-on: https://review.haiku-os.org/c/haiku/+/7185 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff f2acc47f Wed Dec 06 10:38:28 MST 2023 Jérôme Duval <jerome.duval@gmail.com> acpi: update AcpiOsAcquireGlobalLock and AcpiOsReleaseGlobalLock implementations from FreeBSD. Because the argument wasn't volatile, the compiler wasn't considerung reading the lock content. * fix the acquire and release loops: The loop could be exited when any new values were read. Instead the return value should be checked against the old value. Old x86 gcc2 asm loop in AcpiOsAcquireGlobalLock: 11660: 89 c8 mov %ecx,%eax 11662: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11666: 39 0a cmp %ecx,(%edx) 11668: 74 f6 je 11660 <AcpiOsAcquireGlobalLock+0x20> New x86 gcc13 asm loop in AcpiOsAcquireGlobalLock: 4d58: 8b 11 mov (%ecx),%edx 4d5a: 89 d0 mov %edx,%eax 4d5c: 89 d3 mov %edx,%ebx 4d5e: 83 e0 fc and $0xfffffffc,%eax 4d61: 83 cb 03 or $0x3,%ebx 4d64: f6 c2 02 test $0x2,%dl 4d67: 75 05 jne 4d6e <AcpiOsAcquireGlobalLock+0x1e> 4d69: 83 c8 02 or $0x2,%eax 4d6c: 89 c3 mov %eax,%ebx 4d6e: 89 d0 mov %edx,%eax 4d70: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d74: 75 e2 jne 4d58 <AcpiOsAcquireGlobalLock+0x8> Old x86 gcc2 asm loop in AcpiOsReleaseGlobalLock: 11690: 89 c8 mov %ecx,%eax 11692: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11696: 39 0a cmp %ecx,(%edx) 11698: 74 f6 je 11690 <AcpiOsReleaseGlobalLock+0x10> New x86 gcc13 asm loop in AcpiOsReleaseGlobalLock: 4d88: 8b 11 mov (%ecx),%edx 4d8a: 89 d3 mov %edx,%ebx 4d8c: 89 d0 mov %edx,%eax 4d8e: 83 e3 fc and $0xfffffffc,%ebx 4d91: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d95: 75 f1 jne 4d88 <AcpiOsReleaseGlobalLock+0x8> Change-Id: Ia55ba8666efe8b5c198a01db100b4747b72df4a0 Reviewed-on: https://review.haiku-os.org/c/haiku/+/7185 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff f2acc47f Wed Dec 06 10:38:28 MST 2023 Jérôme Duval <jerome.duval@gmail.com> acpi: update AcpiOsAcquireGlobalLock and AcpiOsReleaseGlobalLock implementations from FreeBSD. Because the argument wasn't volatile, the compiler wasn't considerung reading the lock content. * fix the acquire and release loops: The loop could be exited when any new values were read. Instead the return value should be checked against the old value. Old x86 gcc2 asm loop in AcpiOsAcquireGlobalLock: 11660: 89 c8 mov %ecx,%eax 11662: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11666: 39 0a cmp %ecx,(%edx) 11668: 74 f6 je 11660 <AcpiOsAcquireGlobalLock+0x20> New x86 gcc13 asm loop in AcpiOsAcquireGlobalLock: 4d58: 8b 11 mov (%ecx),%edx 4d5a: 89 d0 mov %edx,%eax 4d5c: 89 d3 mov %edx,%ebx 4d5e: 83 e0 fc and $0xfffffffc,%eax 4d61: 83 cb 03 or $0x3,%ebx 4d64: f6 c2 02 test $0x2,%dl 4d67: 75 05 jne 4d6e <AcpiOsAcquireGlobalLock+0x1e> 4d69: 83 c8 02 or $0x2,%eax 4d6c: 89 c3 mov %eax,%ebx 4d6e: 89 d0 mov %edx,%eax 4d70: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d74: 75 e2 jne 4d58 <AcpiOsAcquireGlobalLock+0x8> Old x86 gcc2 asm loop in AcpiOsReleaseGlobalLock: 11690: 89 c8 mov %ecx,%eax 11692: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11696: 39 0a cmp %ecx,(%edx) 11698: 74 f6 je 11690 <AcpiOsReleaseGlobalLock+0x10> New x86 gcc13 asm loop in AcpiOsReleaseGlobalLock: 4d88: 8b 11 mov (%ecx),%edx 4d8a: 89 d3 mov %edx,%ebx 4d8c: 89 d0 mov %edx,%eax 4d8e: 83 e3 fc and $0xfffffffc,%ebx 4d91: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d95: 75 f1 jne 4d88 <AcpiOsReleaseGlobalLock+0x8> Change-Id: Ia55ba8666efe8b5c198a01db100b4747b72df4a0 Reviewed-on: https://review.haiku-os.org/c/haiku/+/7185 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff f2acc47f Wed Dec 06 10:38:28 MST 2023 Jérôme Duval <jerome.duval@gmail.com> acpi: update AcpiOsAcquireGlobalLock and AcpiOsReleaseGlobalLock implementations from FreeBSD. Because the argument wasn't volatile, the compiler wasn't considerung reading the lock content. * fix the acquire and release loops: The loop could be exited when any new values were read. Instead the return value should be checked against the old value. Old x86 gcc2 asm loop in AcpiOsAcquireGlobalLock: 11660: 89 c8 mov %ecx,%eax 11662: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11666: 39 0a cmp %ecx,(%edx) 11668: 74 f6 je 11660 <AcpiOsAcquireGlobalLock+0x20> New x86 gcc13 asm loop in AcpiOsAcquireGlobalLock: 4d58: 8b 11 mov (%ecx),%edx 4d5a: 89 d0 mov %edx,%eax 4d5c: 89 d3 mov %edx,%ebx 4d5e: 83 e0 fc and $0xfffffffc,%eax 4d61: 83 cb 03 or $0x3,%ebx 4d64: f6 c2 02 test $0x2,%dl 4d67: 75 05 jne 4d6e <AcpiOsAcquireGlobalLock+0x1e> 4d69: 83 c8 02 or $0x2,%eax 4d6c: 89 c3 mov %eax,%ebx 4d6e: 89 d0 mov %edx,%eax 4d70: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d74: 75 e2 jne 4d58 <AcpiOsAcquireGlobalLock+0x8> Old x86 gcc2 asm loop in AcpiOsReleaseGlobalLock: 11690: 89 c8 mov %ecx,%eax 11692: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11696: 39 0a cmp %ecx,(%edx) 11698: 74 f6 je 11690 <AcpiOsReleaseGlobalLock+0x10> New x86 gcc13 asm loop in AcpiOsReleaseGlobalLock: 4d88: 8b 11 mov (%ecx),%edx 4d8a: 89 d3 mov %edx,%ebx 4d8c: 89 d0 mov %edx,%eax 4d8e: 83 e3 fc and $0xfffffffc,%ebx 4d91: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d95: 75 f1 jne 4d88 <AcpiOsReleaseGlobalLock+0x8> Change-Id: Ia55ba8666efe8b5c198a01db100b4747b72df4a0 Reviewed-on: https://review.haiku-os.org/c/haiku/+/7185 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff f2acc47f Wed Dec 06 10:38:28 MST 2023 Jérôme Duval <jerome.duval@gmail.com> acpi: update AcpiOsAcquireGlobalLock and AcpiOsReleaseGlobalLock implementations from FreeBSD. Because the argument wasn't volatile, the compiler wasn't considerung reading the lock content. * fix the acquire and release loops: The loop could be exited when any new values were read. Instead the return value should be checked against the old value. Old x86 gcc2 asm loop in AcpiOsAcquireGlobalLock: 11660: 89 c8 mov %ecx,%eax 11662: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11666: 39 0a cmp %ecx,(%edx) 11668: 74 f6 je 11660 <AcpiOsAcquireGlobalLock+0x20> New x86 gcc13 asm loop in AcpiOsAcquireGlobalLock: 4d58: 8b 11 mov (%ecx),%edx 4d5a: 89 d0 mov %edx,%eax 4d5c: 89 d3 mov %edx,%ebx 4d5e: 83 e0 fc and $0xfffffffc,%eax 4d61: 83 cb 03 or $0x3,%ebx 4d64: f6 c2 02 test $0x2,%dl 4d67: 75 05 jne 4d6e <AcpiOsAcquireGlobalLock+0x1e> 4d69: 83 c8 02 or $0x2,%eax 4d6c: 89 c3 mov %eax,%ebx 4d6e: 89 d0 mov %edx,%eax 4d70: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d74: 75 e2 jne 4d58 <AcpiOsAcquireGlobalLock+0x8> Old x86 gcc2 asm loop in AcpiOsReleaseGlobalLock: 11690: 89 c8 mov %ecx,%eax 11692: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11696: 39 0a cmp %ecx,(%edx) 11698: 74 f6 je 11690 <AcpiOsReleaseGlobalLock+0x10> New x86 gcc13 asm loop in AcpiOsReleaseGlobalLock: 4d88: 8b 11 mov (%ecx),%edx 4d8a: 89 d3 mov %edx,%ebx 4d8c: 89 d0 mov %edx,%eax 4d8e: 83 e3 fc and $0xfffffffc,%ebx 4d91: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d95: 75 f1 jne 4d88 <AcpiOsReleaseGlobalLock+0x8> Change-Id: Ia55ba8666efe8b5c198a01db100b4747b72df4a0 Reviewed-on: https://review.haiku-os.org/c/haiku/+/7185 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff f2acc47f Wed Dec 06 10:38:28 MST 2023 Jérôme Duval <jerome.duval@gmail.com> acpi: update AcpiOsAcquireGlobalLock and AcpiOsReleaseGlobalLock implementations from FreeBSD. Because the argument wasn't volatile, the compiler wasn't considerung reading the lock content. * fix the acquire and release loops: The loop could be exited when any new values were read. Instead the return value should be checked against the old value. Old x86 gcc2 asm loop in AcpiOsAcquireGlobalLock: 11660: 89 c8 mov %ecx,%eax 11662: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11666: 39 0a cmp %ecx,(%edx) 11668: 74 f6 je 11660 <AcpiOsAcquireGlobalLock+0x20> New x86 gcc13 asm loop in AcpiOsAcquireGlobalLock: 4d58: 8b 11 mov (%ecx),%edx 4d5a: 89 d0 mov %edx,%eax 4d5c: 89 d3 mov %edx,%ebx 4d5e: 83 e0 fc and $0xfffffffc,%eax 4d61: 83 cb 03 or $0x3,%ebx 4d64: f6 c2 02 test $0x2,%dl 4d67: 75 05 jne 4d6e <AcpiOsAcquireGlobalLock+0x1e> 4d69: 83 c8 02 or $0x2,%eax 4d6c: 89 c3 mov %eax,%ebx 4d6e: 89 d0 mov %edx,%eax 4d70: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d74: 75 e2 jne 4d58 <AcpiOsAcquireGlobalLock+0x8> Old x86 gcc2 asm loop in AcpiOsReleaseGlobalLock: 11690: 89 c8 mov %ecx,%eax 11692: f0 0f b1 1a lock cmpxchg %ebx,(%edx) 11696: 39 0a cmp %ecx,(%edx) 11698: 74 f6 je 11690 <AcpiOsReleaseGlobalLock+0x10> New x86 gcc13 asm loop in AcpiOsReleaseGlobalLock: 4d88: 8b 11 mov (%ecx),%edx 4d8a: 89 d3 mov %edx,%ebx 4d8c: 89 d0 mov %edx,%eax 4d8e: 83 e3 fc and $0xfffffffc,%ebx 4d91: f0 0f b1 19 lock cmpxchg %ebx,(%ecx) 4d95: 75 f1 jne 4d88 <AcpiOsReleaseGlobalLock+0x8> Change-Id: Ia55ba8666efe8b5c198a01db100b4747b72df4a0 Reviewed-on: https://review.haiku-os.org/c/haiku/+/7185 Reviewed-by: waddlesplash <waddlesplash@gmail.com> |
/haiku/src/add-ons/translators/gif/ | ||
H A D | SavePalette.cpp | diff 4e370115 Wed May 22 15:07:04 MDT 2013 Murai Takashi <tmurai01@gmail.com> GIFTranslator: fix incorrectly initialized fTransparentMode Signed-off-by: Philippe Houdoin <philippe.houdoin@gmail.com> diff f3780ae8 Fri Aug 17 17:24:09 MDT 2012 Alex Smith <alex@alex-smith.me.uk> CID 715700, 715701: Fixed assumption of 4 byte pointer size. diff 758b1d0e Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 4e370115ac11145fd6d4dfc0d8f2ea5aaa36b20d Wed May 22 15:07:04 MDT 2013 Murai Takashi <tmurai01@gmail.com> GIFTranslator: fix incorrectly initialized fTransparentMode Signed-off-by: Philippe Houdoin <philippe.houdoin@gmail.com> diff f3780ae8b2dcd5ae3b30bb9c4ffc36cbac58f3fe Fri Aug 17 17:24:09 MDT 2012 Alex Smith <alex@alex-smith.me.uk> CID 715700, 715701: Fixed assumption of 4 byte pointer size. diff 758b1d0e05fe1042cce6e00d194a147802d4f9be Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e05fe1042cce6e00d194a147802d4f9be Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e05fe1042cce6e00d194a147802d4f9be Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
/haiku/headers/private/graphics/common/ | ||
H A D | debug_ext.h | diff 758b1d0e Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e05fe1042cce6e00d194a147802d4f9be Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e05fe1042cce6e00d194a147802d4f9be Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e05fe1042cce6e00d194a147802d4f9be Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
/haiku/src/system/boot/platform/u-boot/ | ||
H A D | uimage.cpp | diff 4f4270c9 Mon Sep 16 18:42:58 MDT 2013 Ithamar R. Adema <ithamar@upgrade-android.com> loader/u-boot: fix alignment of uimage components. The "blobs" in a U-Boot uimage are aligned at 4 bytes, which we did not take into account. Found this when adding a 3rd blob containing the Flattened Device Tree for ARM. diff 4f4270c9 Mon Sep 16 18:42:58 MDT 2013 Ithamar R. Adema <ithamar@upgrade-android.com> loader/u-boot: fix alignment of uimage components. The "blobs" in a U-Boot uimage are aligned at 4 bytes, which we did not take into account. Found this when adding a 3rd blob containing the Flattened Device Tree for ARM. diff 7418443d Mon Sep 16 18:42:58 MDT 2013 Ithamar R. Adema <ithamar@upgrade-android.com> loader/u-boot: fix alignment of uimage components. The "blobs" in a U-Boot uimage are aligned at 4 bytes, which we did not take into account. Found this when adding a 3rd blob containing the Flattened Device Tree for ARM. diff 4f4270c9902b587f017ff9ea3343ed535baa6f6b Mon Sep 16 18:42:58 MDT 2013 Ithamar R. Adema <ithamar@upgrade-android.com> loader/u-boot: fix alignment of uimage components. The "blobs" in a U-Boot uimage are aligned at 4 bytes, which we did not take into account. Found this when adding a 3rd blob containing the Flattened Device Tree for ARM. diff 4f4270c9902b587f017ff9ea3343ed535baa6f6b Mon Sep 16 18:42:58 MDT 2013 Ithamar R. Adema <ithamar@upgrade-android.com> loader/u-boot: fix alignment of uimage components. The "blobs" in a U-Boot uimage are aligned at 4 bytes, which we did not take into account. Found this when adding a 3rd blob containing the Flattened Device Tree for ARM. diff 7418443d1246959a5d89dad67d56b749a6708c6a Mon Sep 16 18:42:58 MDT 2013 Ithamar R. Adema <ithamar@upgrade-android.com> loader/u-boot: fix alignment of uimage components. The "blobs" in a U-Boot uimage are aligned at 4 bytes, which we did not take into account. Found this when adding a 3rd blob containing the Flattened Device Tree for ARM. |
/haiku/src/add-ons/kernel/network/ppp/shared/libkernelppp/headers/ | ||
H A D | TemplateList.h | diff 758b1d0e Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e05fe1042cce6e00d194a147802d4f9be Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e05fe1042cce6e00d194a147802d4f9be Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e05fe1042cce6e00d194a147802d4f9be Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
/haiku/src/add-ons/kernel/network/ppp/shared/libppp/ | ||
H A D | MessageDriverSettingsUtils.cpp | diff 758b1d0e Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e05fe1042cce6e00d194a147802d4f9be Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e05fe1042cce6e00d194a147802d4f9be Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e05fe1042cce6e00d194a147802d4f9be Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
/haiku/src/apps/soundrecorder/ | ||
H A D | TransportButton.cpp | diff 758b1d0e Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e05fe1042cce6e00d194a147802d4f9be Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e05fe1042cce6e00d194a147802d4f9be Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e05fe1042cce6e00d194a147802d4f9be Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
H A D | UpDownButton.cpp | diff 758b1d0e Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e05fe1042cce6e00d194a147802d4f9be Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e05fe1042cce6e00d194a147802d4f9be Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e05fe1042cce6e00d194a147802d4f9be Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
/haiku/src/bin/ | ||
H A D | roster.cpp | diff 758b1d0e Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e05fe1042cce6e00d194a147802d4f9be Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e05fe1042cce6e00d194a147802d4f9be Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 758b1d0e05fe1042cce6e00d194a147802d4f9be Sat Nov 12 16:27:14 MST 2005 Ingo Weinhold <ingo_weinhold@gmx.de> Fixes that make Haiku build with gcc 4. Mainly out of the following categories: * Missing includes (like <stdlib.h> and <string.h>). * Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so. * Local variables shadowing parameters. * Default parameters in function definitions (as opposed to function declarations). * All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported explicitly from the std:: namespace now. * "new (sometype)[...]" must read "new sometype[...]", even if sometype is something like "const char *". * __FUNCTION__ is no longer a string literal (but a string expression), i.e. 'printf(__FUNCTION__ ": ...\n")' is invalid code. * A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes" is an invalid expression. * "friend class SomeClass" only works when SomeClass is known before. Otherwise the an inner class with that name is considered as friend. gcc 4 is much pickier about scopes. * gcc 4 is generally stricter with respect to type conversions in C. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
/haiku/src/add-ons/kernel/drivers/disk/virtual/ | ||
H A D | Jamfile | diff 8e416d27 Sun Nov 10 07:43:05 MST 2013 Ingo Weinhold <ingo_weinhold@gmx.de> Add a simple RAM disk driver * It uses physical pages directly, not wasting kernel address space. * The user interface is somewhat crude, it uses writes to a control device (output to serial debug/syslog), e.g. echo register 4g > /dev/disk/virtual/ram/control to register a 4 GB RAM disk. It is published under /dev/disk/virtual/ram/<index>/raw and can be formatted with DriveSetup like any other disk. Unregistering is broken ATM. * It's not on the image by default, but can be added via AddNewDriversToHaikuImage disk virtual : ram_disk ; * I found it quite useful when working on large HaikuPorts ports. E.g. mounting a RAM disk at the port's work directory shaves a lot of time off disk heavy operations. Obviously one shouldn't let changes lie around on it without back up. diff 8e416d27 Sun Nov 10 07:43:05 MST 2013 Ingo Weinhold <ingo_weinhold@gmx.de> Add a simple RAM disk driver * It uses physical pages directly, not wasting kernel address space. * The user interface is somewhat crude, it uses writes to a control device (output to serial debug/syslog), e.g. echo register 4g > /dev/disk/virtual/ram/control to register a 4 GB RAM disk. It is published under /dev/disk/virtual/ram/<index>/raw and can be formatted with DriveSetup like any other disk. Unregistering is broken ATM. * It's not on the image by default, but can be added via AddNewDriversToHaikuImage disk virtual : ram_disk ; * I found it quite useful when working on large HaikuPorts ports. E.g. mounting a RAM disk at the port's work directory shaves a lot of time off disk heavy operations. Obviously one shouldn't let changes lie around on it without back up. diff 4d1cc41e Tue May 01 18:38:45 MDT 2007 François Revol <revol@free.fr> skeleton for an fmap driver (IMAGE.BE). Start of an Network Block Device driver. NBD server python script I foundon the net for testing. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20963 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 8e416d27ff2edcf0458e7916357584a4d35c2d58 Sun Nov 10 07:43:05 MST 2013 Ingo Weinhold <ingo_weinhold@gmx.de> Add a simple RAM disk driver * It uses physical pages directly, not wasting kernel address space. * The user interface is somewhat crude, it uses writes to a control device (output to serial debug/syslog), e.g. echo register 4g > /dev/disk/virtual/ram/control to register a 4 GB RAM disk. It is published under /dev/disk/virtual/ram/<index>/raw and can be formatted with DriveSetup like any other disk. Unregistering is broken ATM. * It's not on the image by default, but can be added via AddNewDriversToHaikuImage disk virtual : ram_disk ; * I found it quite useful when working on large HaikuPorts ports. E.g. mounting a RAM disk at the port's work directory shaves a lot of time off disk heavy operations. Obviously one shouldn't let changes lie around on it without back up. diff 8e416d27ff2edcf0458e7916357584a4d35c2d58 Sun Nov 10 07:43:05 MST 2013 Ingo Weinhold <ingo_weinhold@gmx.de> Add a simple RAM disk driver * It uses physical pages directly, not wasting kernel address space. * The user interface is somewhat crude, it uses writes to a control device (output to serial debug/syslog), e.g. echo register 4g > /dev/disk/virtual/ram/control to register a 4 GB RAM disk. It is published under /dev/disk/virtual/ram/<index>/raw and can be formatted with DriveSetup like any other disk. Unregistering is broken ATM. * It's not on the image by default, but can be added via AddNewDriversToHaikuImage disk virtual : ram_disk ; * I found it quite useful when working on large HaikuPorts ports. E.g. mounting a RAM disk at the port's work directory shaves a lot of time off disk heavy operations. Obviously one shouldn't let changes lie around on it without back up. 4d1cc41eb3a998c0661334fa5c4a3baa4ae5461f Tue May 01 18:38:45 MDT 2007 François Revol <revol@free.fr> skeleton for an fmap driver (IMAGE.BE). Start of an Network Block Device driver. NBD server python script I foundon the net for testing. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20963 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
Completed in 311 milliseconds