[haiku-commits] Re: BRANCH mmadia-github.separate-build-environment - in headers/build: posix_target os_target/storage

  • From: Matt Madia <mattmadia@xxxxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Thu, 9 Aug 2012 22:18:35 -0400

On 8/9/12, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> On 2012-08-09 at 00:22:58 [+0200], Matt Madia <mattmadia@xxxxxxxxx> wrote:
>> On 8/8/12, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
>> > Why not define a _haiku_build_size_t?
>>
>> I honesty didn't consider doing that. Should this go in
>> headers/build/config_target/target_types.h?
>>   typedef _HAIKU_BUILD_FEATURE___SIZE_TYPE__    _haiku_build_size_t ;
>
> I believe stddef.h is supposed to provide the size_t type, so the
> corresponding target header would be a more suitable place.

But isn't stddef.h one of the headers that won't be getting a target_*
counterpart?

>> > That aside, __SIZE_TYPE__ is defined directly by the compiler (e.g. try
>> > "echo __SIZE_TYPE__ | gcc -E -"), so there's no point in wrapping it
>> > either.
>>
>> Since you mentioned using _haiku_build_size_t, the visual uniformity
>> does appeal to me.
>
> I wasn't arguing against the typedef. I was just pointing out that
> _HAIKU_BUILD_FEATURE___SIZE_TYPE__ is superfluous, since __SIZE_TYPE__ is
> not defined in a header, but by the compiler itself, so you can just as
> well use it directly. I also don't think it is required by any standard, so
>
> it might be gcc specific. Consequently size_t would need to be imported
> like the fixed-width integer types.

And that would be by copying PRINT_TYPE_INFO(size_t); and related code
into test_stddef_header.cpp?

--mmadia

Other related posts: