Searched hist:4 (Results 101 - 125 of 3871) sorted by relevance

1234567891011>>

/haiku/3rdparty/korli/
H A Dhaiku-current.list4a55cc23 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 DStatusMenuField.cpp4fc18643 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 DStatusMenuField.h4fc18643 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 Dping.h3bf4cdb7 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 Dping6.h3bf4cdb7 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 Dutils.c3bf4cdb7 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 Dutils.h3bf4cdb7 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 Dmain.h3bf4cdb7 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 Dtr.catkeysdiff 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 Dtheatre_out.cdiff 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 DDirectoryIterator.hdiff 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 Dexfat.hdiff 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 DJamfilediff 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 DDirectoryIterator.cppdiff 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 DJamfilediff 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 Dachaiku.hdiff 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 DSavePalette.cppdiff 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 Ddebug_ext.hdiff 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 Duimage.cppdiff 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 DTemplateList.hdiff 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 DMessageDriverSettingsUtils.cppdiff 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 DTransportButton.cppdiff 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 DUpDownButton.cppdiff 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 Droster.cppdiff 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 DJamfilediff 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

1234567891011>>