Lines Matching refs:open

30 - Missing arguments to functions (e.g., `open()` with `O_CREAT`, but no mode
401 ## Breakdown of open
403 In Bionic, the [FORTIFY'ed implementation of `open`] is quite large. Much like
407 int open(const char* __path, int __flags, ...);
413 int __open_real(const char*, int, ...) __asm__(open);
418 int open(const char* pathname, int flags, mode_t modes, ...) __overloadable
425 int open(const char* const __attribute__((pass_object_size(1))) pathname, int flags)
430 "'open' called with O_CREAT or O_TMPFILE, but missing mode"))) {
441 int open(const char* const __attribute__((pass_object_size(1))) pathname, int flags, mode_t modes)
444 "'open' has superfluous mode bits; missing O_CREAT?") {
453 real way that Bionic tries to prevent calls to `open` like
454 `open("foo", 0, "how do you convert a const char[N] to mode_t?");`. The only
459 incompatible argument types, cannot go to any `open` implementation other than
464 This `open` implementation does a few things:
465 - Turns calls to `open` with too many arguments into a compile-time error.
466 - Diagnoses calls to `open` with missing modes at compile-time and run-time
468 - Emits warnings on calls to `open` with useless mode bits, unless the mode bits
473 int __open_real(const char*, int, ...) __asm__(open);
483 int open(const char* pathname, int flags, mode_t modes, ...) __overloadable
487 Which matches most calls to open that supply too many arguments, since
494 The following overload handles all two-argument calls to `open`.
500 int open(const char* const __attribute__((pass_object_size(1))) pathname, int flags)
505 "'open' called with O_CREAT or O_TMPFILE, but missing mode"))) {
515 to `open` is broken in a way that's visible to Clang's frontend. This
516 essentially boils down to "`open` is being called with a `flags` value that
523 if (needs_mode(flags)) __fortify_fatal("open: called with O_CREAT/O_TMPFILE but no mode");
524 return FDTRACK_CREATE_NAME("open", __openat(AT_FDCWD, pathname, force_O_LARGEFILE(flags), 0));
530 Finally, we have the following `open` call:
536 int open(const char* const __attribute__((pass_object_size(1))) pathname, int flags, mode_t modes)
539 "'open' has superfluous mode bits; missing O_CREAT?") {
548 #### What about `&open`?
549 One yet-unaddressed aspect of the above is how `&open` works. This is thankfully
551 - It happens that `open` takes a parameter of type `const char*`.
593 To get the commonality with `mempcpy` and `open` out of the way:
830 [FORTIFY'ed implementation of `open`]: https://android.googlesource.com/platform/bionic/+/refs/head…
841 …s://android.googlesource.com/platform/bionic/+/refs/heads/android12-release/libc/bionic/open.cpp#70