P4 2016 draft: integer division is actually well-defined in C about p4-spec

[vgurevich]

Hi Ben,

You are right. It has been well defined since C99. It was ANSI C (C89),
where it was let up to implementation (whether to truncate towards 0 or
upwards).

I think a bigger problem is the fact that in some languages "%" stands
either for modulo (e.g. in Python) or for the remainder (e.g. in C), the
difference being whether the sign of the result is the same as in the
second operand or as in the first and thus many programmers are a little
wary every time they see "/" or "%" anywhere near operands with different
signs.

Having said that, I agree that we can remove that particular editorial from
the spec :)

Happy hacking,
Vladimir

On Tue, Aug 16, 2016 at 3:19 PM, Ben Pfaff [email protected] wrote:

Section 10.6 says:

Division and modulo are illegal for negative values (the C language does
not give a clear semantics to division of signed integers when values are
negative).

but this is incorrect. The ISO C standard for C, 2011 edition, defines
division clearly and unambigiously as the following in section 6.5.5
"Multiplicative operators" (this has only been clarified slightly since the
1999 edition):

When integers are divided, the result of the / operator is the algebraic
quotient with any
fractional part discarded. 105) If the quotient a/b is representable, the
expression
(a/b)*b + a%b shall equal a; otherwise, the behavior of both a/b and a%b is
undefined.
105) This is often called ‘‘truncation toward zero’’.

It's one thing if P4 doesn't want to define this but it shouldn't make
incorrect claims about the C language.

Even if we don't want to define division for negative values, it's
probably best if P4 defines 0/x as zero instead of forbidding it.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#40, or mute the thread
https://github.com/notifications/unsubscribe-auth/AMPb8-PJimJ-UT-cBGe_BXbkxoB67oOaks5qgjePgaJpZM4Jl6Nh
.

[jnfoster]

I would be in favor of removing nearly all references to other languages from the P4-16 specification. It's fine to say in the preamble that the language is C-like, but it would be best if the specification was as self-contained as is practical. The current draft references ideas from C, C++, C#, and Java on many pages (I started marking them up as Word comments -- there are dozens of these). If we assume that the reader is intimately familiar with the dark corners of the specifications of these languages, we greatly increases the knowledge needed to understand P4, which is a real shame. Moreover, in many cases, the P4 construct is not precisely the same as in the language being referred to, so making an analogy is arguably more harmful than helpful.