[Geany-devel] [geany/geany] 795ee4: Merge pull request #28 from RetroX/patch-1

Lex Trotman elextr at xxxxx
Sat Feb 25 23:57:18 UTC 2012

On 26 February 2012 10:31, Erik de Castro Lopo <mle+tools at mega-nerd.com> wrote:
> Lex Trotman wrote:
>> I have thought about which types should be "automagically" present in
>> Geany without a tags file, and I do not think the intN_t types
>> qualify.  They are not fundamental,
> In C99 they are.
>> they require header <cstdint> to
> Thats C++. I'm pretty sure all the C99 intN_t types were added to
> the latest C++ standard as well.

The changes we are talking about are to filetypes.cpp which is c++

The intN_t types are in <cstdint> header, they are not fundamental and
as I said they are not required.

>> Also it is bad practice to be using fixed size types, especially as
>> they are not actually guaranteed to exist.
> All compliant C99 implementations *must* provide the standard intN_t types.

No, they are optional in C as well, an implementation on an embedded
processor does *not* have to supply a fixed width twos complement 64
bit type unless it happens to have one.  A processor does not have to
address 8 bits, it could address 16 bits in which case int8_t won't

>> If they are used they
>> should be typedefed to a more user friendly name.
> I am sure I am not the only one who considers
>    typedef int32_t my_project_int16_t ;
> to be bad practice.

Indeed, but it is good practice to typedef uint8_t to octet to
represent utf8 octets instead of splattering uint8_ts everywhere,
thats what I mean.

>> So I suggest that only the fundamental types and <cstddef> types
>> size_t, nullptr_t ptrdiff_t and max_align_t should be available by
>> adding them to the secondary keyword list for C++.
> Please do not conflate C++ with C.

As I said the changes were to filetypes.cpp which is the C++ filetype
file.  I mentioned in a previous post that something similar should be
done to the C types, but that isn't the current point.


More information about the Devel mailing list