[PATCH] D67867: [libc] Add few docs and implementation of strcpy and strcat.

[Siva Chandra via Phabricator via llvm-commits]

sivachandra added a comment.

In D67867#1684562 <https://reviews.llvm.org/D67867#1684562>, @dlj wrote:

> In D67867#1684296 <https://reviews.llvm.org/D67867#1684296>, @MaskRay wrote:
>
> > Some tests will involve several functions from a header, e.g. flockfile+ftrylock+funlockfile. Where will you place the test, under flockfile/, or funlockfile/ ?
> >
> > I prefer jyknight's proposed hierarchy.
>
>
> The source tree layout should probably reflect the structure of implementation (which we decide and work within), not just the structure of the interface (which is specified for us).
>
> Another way to think about it: within the implementation, how can we localize changes?
>
> Siva mentioned tests, and I think that's quite instructive: the testing boundary provides a natural cut point for functions that must be tested mutually.
>
> File locking functions are practically inseparable, so it's reasonable to keep them together. However, that doesn't imply they should be grouped with unrelated functions, nor that all functions should be lumped together. A finer-grained directory structure seems quite intuitive for expressing these chunks of inseparable functionality.


I understand maskray's concerns about related functions. I also agree with what dlj says, so I have updated the implementation standard to say that implementation of related groups of functions will be in their own directories (previous wording said that every function/entrypoint will be in its own directory.)



================
Comment at: libc/docs/header_generation.md:38
+
+## Parameter Syntax
+
----------------
dlj wrote:
> sivachandra wrote:
> > dlj wrote:
> > > Wording nit: the distinction between "parameter" and "argument" caught me a bit by surprise: the "arguments" here are what I would call "parameters" -- things that parameterize the target; the term "parameters" here are free-floating values, but they could be passed as as what I would call "arguments." (This is mostly following the way these terms are used in C++: functions are parameterized, call expressions have arguments.)
> > > 
> > > I really don't want to get into a bikeshed argument here, though. If you don't agree with my reasoning, I can live with this as-is, too. :-)
> > I agree there was some mix up. I made minor changes now. How does it look?
> This is definitely more consistent, but I think it's still the reverse of what I had in mind: "${thing}" is a specific value that exists at call sites, so I would call that an argument. The thing defined by the called function (with unspecified value) is a parameter.
> 
> 
> ```
> int foo(int a); // 1 parameter named "a"
> int b;
> int c = foo(b); // 1 argument named "b"
> ```
> 
> The usage below of "Parameters" in `include_file` matches my expectation, but "Arguments" for `begin` seems at odds with this.
> 
> (The specific wording I'm thinking of is in the C++ standard: [dcl.fct] and [expr.call].)
Ah, I think I understand whats going on now. I think I got mixed up here. Fixed it now (I hope).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67867/new/

https://reviews.llvm.org/D67867