On Mac OSX Mojave 10.14.6, the following simple code does not work anymore :
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <errno.h>
#include <string.h>
int main(int argc, char** argv)
{
int fd = open ("/dev/rdisk0", O_RDONLY);
if (fd == -1)
{
fprintf(stdout, "open(%s) error = %s\n", "/dev/rdisk0", strerror(errno));
fflush(stdout);
return 1;
}
return 0;
}
It gives :
open(/dev/rdisk0) error = Operation not permitted
This happens even when running the executable using sudo.
This code used to work under 10.13 and earlier versions.
Thinking this might be due to SIP, I gave the Terminal and the executable Full Disk Access but it didn't help.
Is there another way to get around this issue? How do I open /dev/rdisk0 now ?
Thanks in advance
Related
I'm using package msys2/gcc in a 64-bit MSYS2 installation, under Windows 10 64-bit.
Sample C program:
#include <stdio.h>
#include <errno.h>
#include <sys/ipc.h>
#include <sys/shm.h>
#include <sys/stat.h>
int main(void)
{
uint64_t key = ftok("shm.exe", 8);
printf("%llx\n", key);
int r = shmget(key, 1024, S_IRUSR|S_IWUSR|IPC_CREAT);
if ( r == -1 )
printf("FAIL %d\n", errno);
else
printf("OK\n");
}
When I run this from the MSYS2 shell I get FAIL 88 which is ENOSYS indicating that shmget is not implemented.
Is it possible to make the call work? The full program also uses semget and semop.
From googling it seems there is a lot of source code in MSYS2 related to SYSV IPC but perhaps something needs to be enabled somewhere.
Not sure why Xcode complains "Use of undeclared identifier 'printf_s' did you mean 'printf'? Try to find help from Xcode manual but not useful.
#include <iostream>
#include <stdio.h>
int main(int argc, const char * argv[]) {
printf_s("Line one\n\t\tLine two\n");
return 0;
}
this is almost the same example as in the man page. everything is updated to recent versions. gcc is 4.9.2. gdb is 7.8.1. linux kernel is 3.17.6-1 (64bit). the install is a recent arch bootstrap. here is the whittled down case:
#define _GNU_SOURCE /* Needed to get O_LARGEFILE definition */
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <fcntl.h>
#include <poll.h>
#include <sys/fanotify.h>
int main(int argc, char *argv[]) {
int fd;
fd = fanotify_init(FAN_CLOEXEC | FAN_CLASS_CONTENT | FAN_NONBLOCK, O_RDONLY | O_LARGEFILE);
if (fd == -1) exit(1);
fprintf(stderr, "calling fanotify_mark: fd=%d\n", fd);
if (fanotify_mark(fd, FAN_MARK_ADD | FAN_MARK_MOUNT, FAN_OPEN_PERM | FAN_CLOSE_WRITE, -1, "/") == -1) exit(2);
fprintf(stderr, "in gdb step through with 'n' for repeat.\n");
fprintf(stderr, " (and sometimes otherwise), a ^C works, but a ^Z and then ^C does not.\n");
}
most of the time, this works fine, but sometimes it does not. I think this is when fanotify_mark never returns. on trying to debug this, I found that I can(not) replicate this for debugging. if I use gdb and try to step through with 'n', fanotify_mark() never returns and is uninterruptible (^C, ^Z).
is this replicable elsewhere, or am I doing something wrong?
/iaw
this happens because FAN_OPEN_PERM requires another program to grant permission. this is almost verbatim from the example in the fanotify man page---and this makes it rather unfortunate, because whittling down the program can induce a hard OS block. so watch it.
my actual intent was to monitor file accesses. for this, one uses FAN_OPEN, not FAN_OPEN_PERM.
I have a very simple Command Line Tool in Xcode:
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
int main(int argc, const char * argv[])
{
void *p = calloc(32, 1);
assert(p);
free(p);
return 0;
}
When I run Instruments->Allocations it shows one living block. The free seems to be ignored.
In the olden days, I remember that you could actually still use the last free'ed block. So I tried this:
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
int main(int argc, const char * argv[])
{
void *p = calloc(32, 1);
assert(p);
free(p);
void *q = calloc(32, 1);
assert(q);
free(q);
return 0;
}
Now, Instruments->Allocations shows no living blocks. This seems correct.
Can anyone explain or reproduce the problem I am seeing in the first program?
I'm using Xcode 4.1.1
Thanks.
Let me rephrase the comments above.
Apple LLVM in Xcode 5 resolved the alloc / free behavior so that no blocks allocated now, thus the free() method runs as expected.
I'm using Xcode 3.2 on Mac OS 10.6 to build a very simple HelloWorld program for CUDA
but it fails to build .. any ideas !!!
this is the code :
#include <iostream>
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
#include <CUDA/CUDA.h>
__device__ char napis_device[14];
__global__ void helloWorldOnDevice(void){
napis_device[0]='H';
napis_device[1]='e';
napis_device[2]='l';
napis_device[3]='l';
napis_device[4]='o';
napis_device[5]=' ';
napis_device[6]='W';
napis_device[7]='o';
napis_device[8]='r';
napis_device[9]='l';
napis_device[10]='d';
napis_device[11]='\n';
}
int main (int argc, char * const argv[]) {
helloWorldOnDevice<<<1,1>>> ();
cudaThreadSynchronize();
char napis_host[14];
const char *symbol="napis device";
cudaMemcpyFromSymbol (napis_host, symbol, sizeof(char)*13, 0, cudaMemcpyDeviceToHost);
return 0;
}
The error appears at this line
helloWorldOnDevice<<<1,1>>> ();
Expected primary-expression before '<' token !!!!!!
You're compiling your program with gcc coming with Xcode. Should use nvcc compiler instead to compile CUDA code. Normally I would use a Makefile to tell that *.cu to be compiled by nvcc and *.cpp by gcc, then link produced objects to an executable.