[PATCH] nvptx: Add _ssize_t as _READ_WRITE_RETURN_TYPE in newlib/libc/include/sys/config.h

[Thomas Schwinge]

Hi Arijit!

On 2025-07-15T14:09:03+0530, Arijit Kumar Das via Newlib <newlib@sourceware.org> wrote:
>> But: won't that change in isolation break the build, or at least warn,
>> given that we've still got 'newlib/libc/machine/nvptx/misc.c':
>>
>>     int
>>     read(int fd, void *buf, size_t count) {
>>
>> ..., that is, 'int' instead of the desire 'ssize_t' return type?
>>
>> In 'newlib/libc/machine/nvptx/write.c' we have:
>>
>>     _READ_WRITE_RETURN_TYPE write (int fd, const void *buf, size_t count)
>>     {
>
> That's a very real possibility, and in fact after some speculation
> it's likely to occur since the
> commit does not change the return type of read() to _READ_WRITE_RETURN_TYPE (aka
> _ssize_t) whereas that's the one for write() in write.c. This causes
> both to have a different
> function signature, which will most definitely cause a CUDA error, if
> not a compile time
> error or warning, as per my earlier experience.
>
>> Apparently, there isn't any diagnostic about the 'int' vs. 'ssize_t' for
>> 'read', but I suggest that you change the return types of both 'read' and
>> 'write' to the actual type, 'ssize_t'.  (Actually, I don't see any
>> '-W[...]' flags get used for an combined-tree GCC/newlib build, huh...)
>
> Okay, so I change it directly to ssize_t instead of _ssize_t?
> (Actually, I followed the convention
> of the other #define -s for _READ_WRITE_RETURN_TYPE from config.h).

I've not researched all the context/history here, but usually it goes
similar to this:

Generic code (for example: 'newlib/libc/include/sys/config.h',
'newlib/libc/stdio/stdio.c'), which has to work for all possible newlib
targets/configurations, is often using some indirections/abstractions
(for example: '_ssize_t' corresponding to the actual 'ssize_t', or
'_READ_WRITE_RETURN_TYPE' corresponding to the actual 'read', 'write'
return type), so that certain targets/configurations are able to "fix up
things" if necessary.

In contrast, the target-specific implementations (for example:
'newlib/libc/machine/nvptx/write.c') can directly use the actual types
(for example: 'ssize_t' instead of '_ssize_t' or
'_READ_WRITE_RETURN_TYPE'); they (mostly) don't need the
indirections/abstractions, as they define (implement) code for the actual
target/configuration.


> Another thing which I was thinking is that, now that my work in
> newlib/libc/machine/nvptx/misc.c
> is functional (albeit, not optimized or following some expected
> standards per se) could I add this
> one too, in my commit? That doesn't break the build, adds some
> functionality, and I can still
> continue working on it and sending my commits without breaking stuff.

:-) I understand you're eager to get your new code out there, but let's
first sort out the '_READ_WRITE_RETURN_TYPE', '_READ_WRITE_BUFSIZE_TYPE'
thing, and then continue to work on the new code some more, test it
properly (via the GCC test suite, for example), and clean it up, etc.
We'll get there.  :-)


Grüße
 Thomas