why they use the word modifies in c  - Page 1
Forum section: electronics / beginners

author: khatus
author_rank: Regular Contributor
timestamp: April 28, 2020, 12:41:16 pm
content: Here i want to know why or in what sense the word modifies has been used.

author: TimFox
author_rank: Super Contributor
timestamp: April 28, 2020, 12:51:18 pm
content: In English grammar, an adjectivemodifiesthe noun.

author: Siwastaja
author_rank: Super Contributor
timestamp: April 28, 2020, 01:28:06 pm
content: As a side note, be careful with the listed modifiers. Constructing different datatypes was ****ed up in C originally, because these types are not compatible between different CPU architectures and operating systems, and producingportablecode with them is difficult. This problem was finally fixed in 1999, with the C99 standard, which should be considered mature enough in 2020. C99 brings stdint.h, which gives you logically named and portable data types, such as:int32_t: a signed number with 32 bits (range -2147483648 to +2147483647)uint8_t: an unsigned number with 8 bits (range 0 to 255)Int, long int, short int etc. can basically be "anything" and are not very useful, or at least you need to know the standard, and carefully consider they are what you actually want.

author: coppice
author_rank: Super Contributor
timestamp: April 28, 2020, 01:35:42 pm
content: While lots of people writelong i;the full form islong int i;so the word long has modified the word int.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: April 29, 2020, 08:47:32 pm
content: Completely agree wit Siwatiwatsa.C is an old language and some of the stuff in it is for historical reasons, just to keep old code running.C99 is some 30 years old now, and if you care about the number of bits in an integer, then use the typedef values from stdint.h.These modifiers are not completely obsolete though.If you look in stdint.h you will see things like:Code:/* Unsigned. */typedef unsigned char uint8_t;typedef unsigned short int uint16_t;typedef unsigned long int uint32_t;#ifdef __SDCC_LONGLONGtypedef unsigned long long int uint64_t;#endifEdit:About portability remark below:The code above is a snippet from the SDCC compiler. The people who wrote that compiler know under what circumstances the comiler uses a particular number of bits for an "int". SDCC is a relatively simple compiler mostly made long ago for cross compiling 8051 stuff.If you look at stdint.h from some of the many GCC variants then you'll see they have to go to a lot of trouble to make sure that an int16_t always is an int with 16 bits of data.Obsolescence:Using "long" "int" etc, is obsolete for program writers. It's not obsolete for for the compiler maintainers. Users should just never use "int" anymore since C99.

author: janoc
author_rank: Super Contributor
timestamp: April 29, 2020, 10:25:39 pm
content: Quote from: Doctorandus_P on April 29, 2020, 08:47:32 pmThey are not obsolete but are not portable at all. With the exception of signed/unsigned (which are useful in certain situations) they should be only used by the compiler writers to define these typedefs with an explicitly specified size, nothing more (there is no other way in C to specify how many bits should a type have and the compiler authors know the type size for the architecture and their compiler).In fact, the only type with an explicitly defined size in the standard is char which is defined as having 8 bits (a byte).For ex. long int can be 32bits if you are on a 32bit x86 ABI and 64 bits if using the 64bit ABI on the same hw. The same for short and int. It also depends on the compilers.

author: dmills
author_rank: Super Contributor
timestamp: April 30, 2020, 01:01:52 am
content: Char is defined as the smallest addressable unit of memory, not as 8 bits.There are conforming implementations where sizeof char == sizeof short == sizeof int == 1. The analogue devices Shark DSP springs to mind.POSIX however does expect 8 bit bytes.

author: coppice
author_rank: Super Contributor
timestamp: April 30, 2020, 01:05:54 am
content: Quote from: dmills on April 30, 2020, 01:01:52 amIts not just the Shark that has an non-8bit char. Most DSPs had a char that was either 16 or 24 bits. There might well have been something with a 32 bit char, but I can't remember one off hand.

author: dmills
author_rank: Super Contributor
timestamp: April 30, 2020, 11:38:04 am
content: The shark is the one with the 32 bit char, being as the smallest addressable unit of memory on that processor is 32 bits. Perfectly compliant with the C standard.

author: madires
author_rank: Super Contributor
timestamp: April 30, 2020, 12:40:33 pm
content: Some food for thought about portability:Code:int32_t MyValue;char *Check = NULL;MyValue = strtol(SomeString, *Check, 10);vs.Code:long MyValue;char *Check = NULL;MyValue = strtol(SomeString, *Check, 10);Which one is portable? Which one supports a 32-bit and a 64-bit CPU?

author: coppice
author_rank: Super Contributor
timestamp: April 30, 2020, 12:47:45 pm
content: Quote from: madires on April 30, 2020, 12:40:33 pmI assume the point you are trying to make is that there is a place for "give me the longest int" and "give me the natural, most efficient int". The stdint.h and inttypes.h files have types for this, alongside types like int32_t and int64_t. Using long is vague, and no guarantee of anything.

author: Siwastaja
author_rank: Super Contributor
timestamp: April 30, 2020, 02:13:00 pm
content: Quote from: madires on April 30, 2020, 12:40:33 pmThe question makes little sense because strtol, by definition, returns long int, whatever it happens to be. It's only logical to store "long int" in "long int". But depending on system, it may be 32 bits, 64 bits, or something else. But you are limited by the library, not by your own code here.strtoll returns long long int.inttypes.h defines (https://pubs.opengroup.org/onlinepubs/009695399/basedefs/inttypes.h.html) strtoimax, which returns intmax_t, which is the "maximum width integer type".Sadly, writing portable code when using C standard library functions is far from trivial. Long long is guaranteed to be at least 64-bits, so neither of your examples works if you need portable 64-bit value from 32-bit and 64-bit systems. You need to use strtoll instead.

author: coppice
author_rank: Super Contributor
timestamp: April 30, 2020, 02:33:36 pm
content: Quote from: Siwastaja on April 30, 2020, 02:13:00 pmWhat is really sad is that people realised the limitations of the original C types very early on, but it took until 1999 to define sane types. By that time a huge amount of code has defined it own names for well controlled variable types, which are mutually incompatible, and all additions to the library up to C99 used poorly considered parameter and return types, because they had no sane ones to choose amongst.

author: madires
author_rank: Super Contributor
timestamp: April 30, 2020, 04:00:43 pm
content: Quote from: Siwastaja on April 30, 2020, 02:13:00 pmA 64-bit system most likely returns a 64-bit value for strtol(). So strtoll() would return a 128-bit value. But to be sure one would have to check. As you can see, strtoll() has the same issue as strtol(). intX_t and uintX_t make sure that you get the requested bit width, though they might cause a clash with library functions. Portability is a complex topic.

author: TimFox
author_rank: Super Contributor
timestamp: April 30, 2020, 04:29:48 pm
content: Yes, I answered the original question: "Here i want to know why or in what sense the word modifies has been used."In English, the grammatical use is not the only meaning of "to modify".

author: free_electron
author_rank: Super Contributor
timestamp: April 30, 2020, 05:24:04 pm
content: Quote from: Siwastaja on April 28, 2020, 01:28:06 pmThis is the biggest source of problems with 'c'. They lost an ariane rocket due to this idiocy ... the code was simulated on a 32 bit machine but compiled for a 16 bit microcontroller. yielding an overflow , steering the rocket off course.

author: Siwastaja
author_rank: Super Contributor
timestamp: May 01, 2020, 08:04:09 am
content: Quote from: free_electron on April 30, 2020, 05:24:04 pmYes, although to be fair, for low-level embedded work (with minimalistic C library, or completely own code), stdint.h from 1999 completely solves the issue, you just need to use it.On higher level, the problem is still there because working with C standard library functions is still complex for portability.

author: Nerull
author_rank: Frequent Contributor
timestamp: May 01, 2020, 08:55:23 am
content: The Ariane code was was written in Ada, not C. Conversion of 64-bit floating point values to 16-bit values was a known possible issue but processor resources were limited so only 4 of the 7 such conversions in the code were given overflow protection. One of the three was the Horizontal Bias value, which was assumed to not overflow because it didn't on Ariane 4. Ariane 5's trajectory was different, which did cause an overflow. The overflow as detected and triggered an exception. The exception handling method was to assume that any exception indicated a processor fault and initiate CPU shutdown. Both redundant processors had the same error, both shut down, control was lost.The issue had nothing to do with accidental conversions because they developed on one platform and ran the code on another. These were all explicit conversions between types, as Ada has a much stronger typing system than C.

author: Karel
author_rank: Super Contributor
timestamp: May 01, 2020, 09:57:00 am
content: Quote from: Siwastaja on April 28, 2020, 01:28:06 pmI completely agree.Having said that, I always use int, long long, short, char, etc. (but never long because it can be 32 or 64 bit).The reason is that I always use GCC so there's no need to use the standardized variables.I also don't feel the need to be compatible with other compilers.

author: coppice
author_rank: Super Contributor
timestamp: May 01, 2020, 12:00:27 pm
content: Quote from: Karel on May 01, 2020, 09:57:00 amFor some target processors GCC's int is 16 bits, for others its 32 bits, and I think one of the MCU ports made it 8 bits.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: May 01, 2020, 12:53:26 pm
content: Karel's comment is not worth reading, nor commenting about.I'm almost certain that an int is never less then 16 bits, but I really do not care anymore. It's just obsolete (for normal programmers). Just use the C99 typedefs.A slight annoyance with my AVR programming (where every kB counts) is that the type for a switch is normally defined as at least 16 bits, while a switch() will very rarely have more then 256 cases and an uint8_t is fine, saves flash and execution time. GCC has a switch to use 8 bit var's for a switch(), but if you use it you are deviating from standards, and have to keep track of such details for the rest of eternity. Because long term maintenance of code is more important then such slight optimisations I decided to just live with the 16 bit vars for a switch().It's part of the art of programming. If anyone else (or myself after a few years) ever reads that code, they will not get distracted (nor even notice) the thought that went into not deviating from standards. They (and I) have more important bugs to chase.

author: Siwastaja
author_rank: Super Contributor
timestamp: May 01, 2020, 12:55:33 pm
content: Quote from: Karel on May 01, 2020, 09:57:00 amWat?? No, no! int on gcc can be anything at least 16 bits, and actually often is 16, 32 or 64 bits!16 bits on AVR (unless -mint8 is given on command line, in which case it's 8 bits (against C standard). When you need the performance, and you often do, useunsigned charor, even better, uint8_t in loops with max iteration count of 255, instead).32 bits on ARM Cortex-M0 to ARM Cortex-M732 bits or 64 bits on Raspberry Pi, depending on what OS version you are running; this is an example where the number of bits in neitherintnor pointers necessarily match the 64-bit CPU.32 bits on some older PCs.64 bits on most modern PCs.All using GCC.No, these are all systems you very likely encounter today, and no, limiting yourself to one compiler (such as gcc) doesn't help the slightest.No problem in usingintif youdorealize your values are 100.000% surely never going outside range -32768 to +32767.Know your ranges! stdint.h is great because the bit widths (hence, ranges) are explicitly given in thenames, you don't have to remember the C standard.If you use the old style names such as short int, long int, long long int, then it's best to really remember what the standard says about their widths, by heart.Note that int32_fast_t is often the thing you actually want to use as a portable replacement for where you mostly used to useint. It's 32 bits on systems where int is 32 bits, and likely 64 bits on systems where int is 64 bits, but never 16 bits, which int might be.Assuming int is always at least 32 bits is a common mistake; using int32_fast_t instead fixes that as it satisfies this assumption.

author: Nerull
author_rank: Frequent Contributor
timestamp: May 01, 2020, 01:05:36 pm
content: Quote from: Doctorandus_P on May 01, 2020, 12:53:26 pm'int' defaults to unsigned 8 bits in the CCS C Compiler for PIC18, though its a steaming pile of garbage in any case.

author: Siwastaja
author_rank: Super Contributor
timestamp: May 01, 2020, 01:08:42 pm
content: Quote from: Nerull on May 01, 2020, 01:05:36 pmThere are many special embedded and DSP "C" compilers which do not even try to implement the standard C language, but a C-like language of their own. There's nothing wrong with this, as long as you know it. This isn't always obvious, though. The purpose is to make the language look more appealing and easier to write small programs for people who do not know or have experience in the C language (and especially have never read the standard). This isn't necessarily a bad goal, either, and it provably works, but causes interesting clashes when someone more experienced in C tries to work with such tools.

author: coppice
author_rank: Super Contributor
timestamp: May 01, 2020, 01:10:33 pm
content: Quote from: Siwastaja on May 01, 2020, 12:55:33 pmOn a modern 64 bit PC a GCC "int" is a 32 bit value. I'm not sure about a 64 bit Raspberry Pi, but I think its the same. However, you are right about the AVR as well as the MSP430, PIC and other small machine ports using a 16 bit value for an "int". Your comment about the special mode for the AVR must be where I remembered the thing about 8 bit ints.GCC was ported to some DSPs, so there might be machines with a 24 bit "int". There are certainly some other C compilers for DSPs where an "int' is 24 bits.

author: Karel
author_rank: Super Contributor
timestamp: May 01, 2020, 01:53:42 pm
content: Quote from: Siwastaja on May 01, 2020, 12:55:33 pmNo, when using GCC, an int is always 32 bits on x86_64 & x86_32. Also on STM32 and PIC32.I have never had any troubles by doing so, except many years ago with long int.Since then I never use long int anymore (except some special usecase where there's no other solution).But I admit I should start to use the data types declared in stdint.h

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 01, 2020, 03:56:24 pm
content: Quote from: coppice on May 01, 2020, 01:10:33 pmYes.32-bit Linux and Windows are ILP32 architectures, with 32-bit int, long, and pointers.64-bit Linux (on all currently maintained 64-bit hw, not just AMD64/x86-64) is LP64, with 32-bit ints, and 64-bit long and pointers.64-bit Windows is LLP64, with 32-bit ints and longs, and 64-bit long long and pointers.

author: janoc
author_rank: Super Contributor
timestamp: May 01, 2020, 07:15:05 pm
content: Quote from: dmills on April 30, 2020, 01:01:52 amThat has nothing to do with neither POSIX nor smallest addressable memory unit. That short and int are 1 byte on those implementations is irrelevant - standard only says that short has to be at least the size of char and int has to be at least the size of short. That has no implications on the size of char.Concerning the size of the char type, the standard (late draft for C11)http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdfsays (p. 39, paragraph 3):Quotep.90, paragraphs 2 and 4 on thesizeofoperator:QuoteQuote(emphasis mine)And finally, p. 26 on limits.h where char type is specifically mentioned as:QuoteSo yes, char is defined to be 8 bits wide.

author: janoc
author_rank: Super Contributor
timestamp: May 01, 2020, 07:27:00 pm
content: Quote from: Karel on May 01, 2020, 09:57:00 amHoly smokes, Karel, your code has to be real pleasure to work with, especially if you have to deal with things like network protocols or file formats that have explicitly specified field lengths.And even if you only ever use GCC, you can easily get bitten by this - I had to fix exactly this type of a bug in a very popular sensor fusion code that was assuming that int is always 32bits. Well, until it wasn't one day on one platform, despite using GCC!There are some very good reasons why those typedefs have been introduced, especially on embedded platforms where you are dealing with bitwise arithmetic a lot and knowing the exact size of the type is essential. Instead of blindly assuming that the code you took from one MCU will work fine on another.Let's hope you don't get bitten by this in anything critical.

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 01, 2020, 08:49:01 pm
content: FWIW,sizeof (short) == sizeof (int) == 2when using GCC to compile to AVR.

author: Karel
author_rank: Super Contributor
timestamp: May 02, 2020, 07:23:42 am
content: Quote from: janoc on May 01, 2020, 07:27:00 pmI guess I'm lucky that:1. I always use GCC (I simply refuse to use any other compiler)2. our projects so far always used platforms like PIC32, STM32, x86_32 and x86_64On a side note, I wrote (and I still maintain and add new feautures to it) a reasonable big and complex pieceof opensource software that compiles and runs on Linux, Mac and windows (no matter 32 or 64-bit) and I'mstill not bitten in the ass.Again, I don't promote it. I agree it's better to use the standardized data types.

author: janoc
author_rank: Super Contributor
timestamp: May 02, 2020, 10:52:48 am
content: Quote from: Karel on May 02, 2020, 07:23:42 amAll it takes is to change between an 8 bit vs 32 bit platform (e.g. AVR vs PIC32/ARM) or 32bit vs 64bit (all PC platforms). Pointer sizes change, if you cast pointers to ints or vice versa (e.g. in order to access memory-mapped hw), boom. Long int size changes, boom. 8bit AVR has int that is only 16 bits - if you try to compile code ported from ARM on it, boom.The worst bit is that most of those errors will not end up in a crash (well, maybe except those involving pointers) but will leave you with bad data. Which can be really difficult to debug.Even ifyou, personallynever work on any other platform than one using GCC and having 'standard' (in quotes because there is no standard on this) data type sizes (your STM32, PIC32 and x86 all conveniently happen to have the same type sizes and x86_64 differs only in pointer and long int sizes), you can't know who will take your code and try to compile it on another system, with a different compiler. That's especially true if you are publishing open source code for some sort of reusable library (e.g. drivers for various ICs). They will hate your guts for having to debug and fix these issues.

author: Karel
author_rank: Super Contributor
timestamp: May 02, 2020, 01:35:15 pm
content: Quote from: janoc on May 02, 2020, 10:52:48 amI write in all README files that the project MUST be compiled exclusively with GNU make & GCC.If somebody, after reading this, chooses to go against it, and start to blame me because he discoveredthe hard way that it's not possible (despite I told him so), then I guess it's not my problem.I remember a case where somebody started to use visual studioHe got lot's of compiler errors and started to fix them. In the process he started to changes literals like 0b10001110to something else but he didn't understood the full meaning of "0bxxxxxxx". Imagine the havoc...And yes, I do use GNU extensions, they are there for my convenience.It's also a political decision. In my utopia, everybody uses GNU tools or otherwise tools that are GPL'ed.The nice thing about creating my own projects is that I'm in charge and I decide what tools to use.If people don't like that, they are free to ignore my projects or they can fork it.The free software I write are not "community" projects. I don't accept pull requests.Users create an "issue" on Gitlab or they send me a bugreport.If I need more "community", I go to a bar, a sports club or whatever.

author: newbrain
author_rank: Super Contributor
timestamp: May 03, 2020, 12:45:42 pm
content: Quote from: janoc on May 01, 2020, 07:15:05 pmI disagree. Char is defined to beat least8 bits wide.Your quote:QuoteIs preceded (in the actual C 11 standard, I don't think the draft differs though) by this:QuoteSo a char can well be more than 8 bits in conforming implementations. The exact same wording can be found in both C99 and C18.

author: coppice
author_rank: Super Contributor
timestamp: May 03, 2020, 01:28:36 pm
content: When they had to choose the length of an "int" for 64 bit processors, part of the choice was to minimise the amount of portability trouble people like Karel would cause, with their poor programming style. It was also constrained by the shortsightedness of the original C terms. They needed to have 16, 32 and 64 bit and possibly 128 bit numbers. If they had made "int" 64 bit, would they have had to call a 16 bit value something odd, like a "short short int", just as some compilers support long long int for 128 bit values? I think they should remove short, int and long from future versions of C, create new primitives in the compiler for a range of word lengths, and have these accessed through definitions in header files. Then we can move towards not including the header file that defines short, int, and long, and gradually purify C programs.

author: Karel
author_rank: Super Contributor
timestamp: May 03, 2020, 01:48:51 pm
content: Quote from: coppice on May 03, 2020, 01:28:36 pmThat's funnyNow I'm causing trouble by offering (not imposing!) open source software that requires a certain compiler in order to work correctly?You are hilarious

author: Siwastaja
author_rank: Super Contributor
timestamp: May 03, 2020, 01:56:07 pm
content: Quote from: Karel on May 03, 2020, 01:48:51 pmAgain, it has absolutely nothing to do with the compiler! Using a certain compiler won't guarantee the types are the same.No matter how many times you say this like a broken record, the fact won't change.intis usually fine, but I'd be more interested in seeing how you deal with pointers, file offsets, and library functions. Here, producing portable code is far from trivial, even if you completely limit yourself to GCC.

author: janoc
author_rank: Super Contributor
timestamp: May 03, 2020, 02:34:59 pm
content: Quote from: newbrain on May 03, 2020, 12:45:42 pmIf you want to cite from the standard, you need to cite in context and everything, not only selectively - the standard also applies as a whole and not only bits that are convenient.You have skipped completely the part on the sizeof() operator where sizeof(char) is defined as exactly 1 byte (so char, logically, cannot be more than 8 bits).Also the part on limits.h where the standard says "shall be equal or greater in magnitude" includes wording specifically excluding CHAR_BIT and MB_LEN_MAX:QuoteI am not a linguist or a language lawyer but to me it seems clear that the exception is applying to the second sentence as well because "their" refers to the "expressions" in the previous sentence which exclude CHAR_BIT.So I hope this settles it.P.S. - allowing char to be wider than 8 bits doesn't make much sense because the standard defines the type wchar_t which can be either 16 or 32 bits, for exactly this purpose.

author: Nerull
author_rank: Frequent Contributor
timestamp: May 03, 2020, 02:54:52 pm
content: C99 Section 3.6:byteaddressable unit of data storage large enough to hold any member of the basic characterset of the execution environment2 NOTE 1 It is possible to express the address of each individual byte of an object uniquely.3 NOTE 2 A byte is composed of a contiguous sequence of bits, the number of which is implementation defined. The least significant bit is called the low-order bit; the most significant bit is called the high-orderbit.char is defined as one byte, but one byte is not defined as 8 bits.If 8-bits was a defintion, there would be no need for CHAR_BITThere are C/C++ implementations with byte sizes of 8, 9, 16, 32, 36, and 64 bits at least, and char cannot be smaller than the implementation byte size.On Analog Devices SHARC DSPs CHAR_BIT = 32, on TI TMS320C28x DSPs CHAR_BIT = 16. These systems are often incapable of addressing on 8 bit boundaries, and thus an 8-bit byte would fail to meet the C99 definition of byte.

author: IanB
author_rank: Super Contributor
timestamp: May 03, 2020, 03:21:08 pm
content: Has anyone seen the OP recently?

author: Karel
author_rank: Super Contributor
timestamp: May 03, 2020, 03:23:35 pm
content: Quote from: Siwastaja on May 03, 2020, 01:56:07 pmYou take my statements out of context. In the context of GCC and x86_32 and x86_64 and STM32,"char", "short", "int", and "long long" have always the same width (the same is valid for "float" and "double" btw).The only exception is the "long" which has a width of 32 or 64 bits depending on the architecture.I don't use the "long", so no problem there.Can you give a practical example where I am wrong when using GCC on the x86_32, x88_64 or STM32 platforms?Quote from: Siwastaja on May 03, 2020, 01:56:07 pmFor file offsets I always use "long long" in combination with fopen64(), fseeko64() and ftello64().The behaviour is the same on x86_32 and x86_64.Quote from: Siwastaja on May 03, 2020, 01:56:07 pmWhere did I write that I want to produce portable code?I produce code that works correctly when using GCC on the before mentioned platforms.

author: newbrain
author_rank: Super Contributor
timestamp: May 03, 2020, 03:24:51 pm
content: Quote from: janoc on May 03, 2020, 02:34:59 pmThe sizeof part only establish that a byte (not a C type) has the same storage characteristics as a char, Nerull correctly quoted the byte definition.The preceding statement is also completely immaterial in this discussion. It only defines (with exception of CHAR_BIT and MB_LEN_MAX) thetypeof the constant expression of the following list. It says nothing about their value and there's a full stop before the "shall be...".That said, if an (u)int8_t typedef exists in stdint.h, a byte/char isguaranteedto be 8 bits (there can't be a smallest object than char, and char must have at least 8 bits, so if an exact sized integer of 8 bits exists, it must be a char). It's not a mandatory type, though.In any case, if you don't like to take my word for it, possibly you'll be satisfied by the officialC99 Rationale, Ch. 5.2.4.2.1:QuoteA Rationale is not normative, I know very well, but I would tend to agree with them.Quote from: IanB on May 03, 2020, 03:21:08 pmNah...I think they got their answer. Still, the debate is interesting in itself (isn't this the destiny of most threads on this forum?)

author: madires
author_rank: Super Contributor
timestamp: May 03, 2020, 03:58:45 pm
content: Quote from: Karel on May 03, 2020, 03:23:35 pm<sys/types.h>: off_t

author: Karel
author_rank: Super Contributor
timestamp: May 03, 2020, 04:19:08 pm
content: Quote from: madires on May 03, 2020, 03:58:45 pmIf I remember well, off_t is 32 bits wide on x86_32 which means you'll have a file size limit of 2GB.

author: coppice
author_rank: Super Contributor
timestamp: May 03, 2020, 04:28:34 pm
content: Quote from: Karel on May 03, 2020, 04:19:08 pmYou must be remembering a long long time ago, before there was support for large files.

author: Karel
author_rank: Super Contributor
timestamp: May 03, 2020, 04:47:43 pm
content: Quote from: coppice on May 03, 2020, 04:28:34 pmYou can enable large file support on x86_32 and in that case off_t will be 64 bits wide.I use long long which is also 64 bits wide. No problem there.

author: coppice
author_rank: Super Contributor
timestamp: May 03, 2020, 04:49:50 pm
content: Quote from: Karel on May 03, 2020, 04:47:43 pmExcept when its 128 bits wide.

author: Karel
author_rank: Super Contributor
timestamp: May 03, 2020, 04:56:43 pm
content: You haven't read the whole thread? I was referring to using GCC on x86_32 and x86_64 platforms.Please explain when a long long is 128 bits.(I know I can be stubborn sometimes but I'm also open to learn new things.)

author: coppice
author_rank: Super Contributor
timestamp: May 03, 2020, 05:05:22 pm
content: Quote from: Karel on May 03, 2020, 04:56:43 pmOriginally you referred to GCC. Now you have narrowed your view to a subset of platforms supported by GCC.Quote from: Karel on May 03, 2020, 04:56:43 pmWhy do you find merit in writing such non-portable code? Its really easy to settle into practices that just compile and run correctly almost everywhere. I assume you believe your code has no future, or you would be trying to protect its value if you did. Much of the important C code we use today started out on 16 bit machines. If your code lasts as well, it will surely need porting to new things.

author: Karel
author_rank: Super Contributor
timestamp: May 03, 2020, 05:13:56 pm
content: Quote from: coppice on May 03, 2020, 05:05:22 pmYou are right. In my first comment I wrote:"The reason is that I always use GCC so there's no need to use the standardized variables."While I intended to say:"The reason is that I always use GCC on selected platforms like x86_32, x86_64 and STM32 so there's no need to use the standardized variables."I apologize and I'll try to express myself better in the futureIn my defense, I also wrote that I don't promote it and one should use the standard definitions.The point I wanted to make is, that for my projects, it's completely fine to do so.

author: Karel
author_rank: Super Contributor
timestamp: May 04, 2020, 05:42:17 pm
content: I started an attempt to use the standardized datatypes and I got the following problem whenchanging a "long long int" to int64_t related to printf():Code:warning: format ‘%lli’ expects argument of type ‘long long int’, but argument 4 has type ‘int64_t {aka long int}’ [-Wformat=]I don't want to disable -Wformat but I do want to get rid from the warning. Is there a solution?

author: madires
author_rank: Super Contributor
timestamp: May 04, 2020, 06:19:54 pm
content: (long long int)my_variable

author: Karel
author_rank: Super Contributor
timestamp: May 04, 2020, 06:25:16 pm
content: Quote from: madires on May 04, 2020, 06:19:54 pmYou are right ofcourse but it doesn't look very elegant. Why is int64_t a typedef from long int?Why not long long int instead?

author: newbrain
author_rank: Super Contributor
timestamp: May 05, 2020, 06:26:35 am
content: Quote from: Karel on May 04, 2020, 05:42:17 pmYes, there is.As the actual type underlying (u)int??_t is not generally known (apart from (u)int8_t, that is forcibly a char type as discussed above), the standard provides, in its slightly less than infinite wisdom, type specific conversion specifiers as macros in chapter 7.8.1 "Macros for format specifiers" (same chapter for C99, C11 and C18).They are defined as character string literals, and have a quite regular form.In your case for an uint64_T it would be PRIu64 for printf and SCNu64 for scanf.Being string literals, they will be concatenated with adjacent string literals in translation phase 6, and only contain the right conversion specifier, so it's up to you to provide the % and the format width and precision, e.g:Code:printf("Here's my uint64_t: %20" PRIu64 "\n", my_uint64);Edit: changed slightly imprecise language

author: Karel
author_rank: Super Contributor
timestamp: May 05, 2020, 07:16:07 am
content: Quote from: newbrain on May 05, 2020, 06:26:35 amThanks newbrain, but that looks even less elegant and it's makes the code less readable (at least to me).Then I prefer the type cast as proposed by madires.

author: newbrain
author_rank: Super Contributor
timestamp: May 05, 2020, 07:57:29 am
content: Quote from: Karel on May 05, 2020, 07:16:07 amSuit yourself- of course the cast will work as long as you pick the longest type available.I, personally, find cast less appealing and elegant and use them very sparingly - especially if a correct standard solution exists.You are not alone in this: I've seen a lot of professionally written code eschewing PRIxxx in favour of casts.Some of the coders were not even aware and changed it when shown, some did not.

author: Mp3
author_rank: Frequent Contributor
timestamp: May 05, 2020, 11:18:58 am
content: Quote from: Karel on May 05, 2020, 07:16:07 amYou don't have to keep trying to prove your coding practices to us. I think this thread ran its course.

author: Karel
author_rank: Super Contributor
timestamp: May 05, 2020, 11:40:15 am
content: Quote from: Mp3 on May 05, 2020, 11:18:58 amNo, I don't have to. But I'm not hurting anybody either.Honestly, I tried to "convert" a project by using the standard datatypes and I ran into all kinds of issues and that's the reason I bring it up.I sincerely wanted to give it try and I know I can be stubborn but, and please believe me, I'm also open to better ideas.

author: coppice
author_rank: Super Contributor
timestamp: May 05, 2020, 11:54:12 am
content: Quote from: Karel on May 05, 2020, 07:16:07 amThat PRIu64 stuff is definitely a PITA for readability, but it is robust and portable - at least as portable as anything from the era before UTF8 can be in 2020.