On 11/28/2014 05:46 AM, Bill Fischofer wrote:
ssize_t (and size_t) are only 4 bytes on 32-bit systems, so they won't
fit on those systems.
Why they won't fit? Mac address is 6 or 8 bytes. Size can be coded even
with 1 byte.
For return codes what's the problem with simple a int as we've used
elsewhere?
Bill
On Thu, Nov 27, 2014 at 3:18 PM, Ola Liljedahl
<[email protected] <mailto:[email protected]>> wrote:
On 27 November 2014 at 19:18, Maxim Uvarov
<[email protected] <mailto:[email protected]>> wrote:
> On 11/27/2014 07:20 PM, Ola Liljedahl wrote:
>>
>> On 27 November 2014 at 17:10, Maxim Uvarov
<[email protected] <mailto:[email protected]>>
>> wrote:
>>>
>>> On 11/27/2014 06:48 PM, Ola Liljedahl wrote:
>>>>
>>>> This is simple and should in practice cover all situations. MAC
>>>> addresses are not of extremely variable size. In practice,
only 48-bit
>>>> and 64-bit MAC addresses (EUI - Extended Unique Identifier)
are used
>>>> AFAIK.
>>>
>>>
>>> Can linux on ioctl(sockfd, SIOCSIFHWADDR, ..) use both 48 and
64 bit
>>> macs?
>>>
>>>> However I would rather return -1 on error (and use ssize_t as the
>>>> return type). As a general convention I think we should use
negative
>>>> values for error and positive values for success. See e.g. POSIX
>>>> read() call.
>>>>
>>>> -- Ola
>>>
>>>
>>> but size_t is unsigned. so that or it int or it's 0 on error,
like Perti
>>> wrote.
>>
>> That's why I referenced read():
>> ssize_t read(int fd, void *buf, size_t count);
>>
>> Uses ssize_t as return type so negative values can be returned.
>>
>>
> Interesting I did so. But not ssize_t, I used size_t and then on
check if
> (-1 == ret)
> gcc errors that I'm comparing signed and unsigned.
>
> is ssize_t signed size?
Right on
I doubt we will be returning MAC addresses larger than would fit
into ssize_t.
>
>
> Maxim.
>
>>> Maxim.
>>>
>>>
>
_______________________________________________
lng-odp mailing list
[email protected] <mailto:[email protected]>
http://lists.linaro.org/mailman/listinfo/lng-odp
_______________________________________________
lng-odp mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/lng-odp
